注释
.jpg "巨大的文件支持 - UGS 使用常量内存！ #302"){kind=avatar}
所有者作者
所有者作者
|
磁盘支持的 JTable 的可能解决方案：PersistentTableModel |
.jpg "巨大的文件支持 - UGS 使用常量内存！ #302"){kind=avatar}
贡献者
|
真的需要 JTable 吗？ 甚至是可视化工具？我从来不需要visulizer。 |
所有者作者
|
您从 jtable 中得到的一件好事是它将 对于可视化工具，很多人将其用作预览工具。也许我会 在 2015 年 12 月 26 日星期六，rugbymauri notifications@github.com写道：
|
合并
贡献者
|
不管它值多少钱，我都不会错过这张桌子。IMO，机器状态指示器足以知道它是否保持缓冲区已满。 我正在查看分析器中的内容（针对 master，而不是这个分支），在我看来，一个主要问题将是滚动日志。我们需要确保 guy 得到修剪，并且理想情况下不会在滚动时不断创建新对象。当用激光运行我的机器时，GC 暂停很重要。 |
所有者作者
|
@philreindl这也是我的结论，普通 jTable 的设计并不是为了处理这么多数据而设计的。我尝试了各种各样的事情，但最终还是按原样离开了表格，但有一个复选框可以一起禁用它（默认情况下禁用它）。 在常量内存分支中，我已经有了文本日志，因此它不会增长超过一定数量，但对象仍在分配中。实际上，通过大量更改，我正在分配更多对象，因为我不再将所有内容都保存在内存中。一旦我解决了内存问题，我可能不得不再次测试流媒体性能。 |
关闭
.png&h=110&w=185&q=90&zc=1&ct=1)
.jpg&h=110&w=185&q=90&zc=1&ct=1)
.png&h=110&w=185&q=90&zc=1&ct=1)
.png&h=110&w=185&q=90&zc=1&ct=1)
许多人已经注意到 UGS 不支持非常大的文件。这是因为 UGS 在操作期间将整个文件的多个副本存储在内存中。具体来说，有 3 个地方将整个文件存储在内存中（还有元数据的额外存储空间！）：
基本上，一个解决方案需要解决上述每个项目才能在常量内存中工作：
当命令被预处理时，它们被构建到 GcodeCommand 对象的集合中。这可以很容易地与预处理数据一起通过管道传输到新的 gcode 文件中。
可视化工具的实现非常天真。我不确定它如何在常量内存中工作，但可以优化内存使用以执行诸如将微小的弧段或线段合并在一起的操作。
JTable 使用的数据可以写入磁盘并在需要时查找。我相信有很多选择。一个可能的资源，另一个。
可以将控制台输出记录到一个文件中，此时可能有一种方法可以使 JTextArea 丢弃旧消息。一个快速的谷歌出现了这可能是一个解决方案。