开源改变世界!!

巨大的文件支持 – UGS 使用常量内存! #302

推推 grbl 2年前 (2023-01-26) 151次浏览
关闭
绕线器 打开了这个问题 2015 年 10 月 14 日 · 6条评论
关闭

巨大的文件支持 – UGS 使用常量内存!#302

绕线器 打开了这个问题 2015 年 10 月 14 日 · 6条评论

注释

巨大的文件支持 - UGS 使用常量内存! #302
所有者

许多人已经注意到 UGS 不支持非常大的文件。这是因为 UGS 在操作期间将整个文件的多个副本存储在内存中。具体来说,有 3 个地方将整个文件存储在内存中(还有元数据的额外存储空间!):

  1. 每行都存储在一个 GcodeCommand 对象中,该对象具有一些额外的元数据。
  2. 如果正在使用可视化工具,每个顶点都存储在内存中——对于弧,这个顶点数据甚至可以比单个命令更大。
  3. GUI 甚至保留自己的副本作为 Swing JTable 组件 (GcodeTable.java) 的一部分,它存储更多的元数据!!
  4. (叹息)GUI 控制台也可能保留此数据的副本,随着操作的执行,该副本会继续增长,从而导致应用程序性能进一步下降。

基本上,一个解决方案需要解决上述每个项目才能在常量内存中工作:

  1. 当命令被预处理时,它们被构建到 GcodeCommand 对象的集合中。这可以很容易地与预处理数据一起通过管道传输到新的 gcode 文件中。

  2. 可视化工具的实现非常天真。我不确定它如何在常量内存中工作,但可以优化内存使用以执行诸如将微小的弧段或线段合并在一起的操作。

  3. JTable 使用的数据可以写入磁盘并在需要时查找。我相信有很多选择。一个可能的资源另一个

  4. 可以将控制台输出记录到一个文件中,此时可能有一种方法可以使 JTextArea 丢弃旧消息。一个快速的谷歌出现了可能是一个解决方案。

巨大的文件支持 - UGS 使用常量内存! #302
所有者作者

这解决了一些问题#301#244#168

巨大的文件支持 - UGS 使用常量内存! #302
所有者作者

磁盘支持的 JTable 的可能解决方案:PersistentTableModel

巨大的文件支持 - UGS 使用常量内存! #302
贡献者

真的需要 JTable 吗?
登录到控制台就足够了。

甚至是可视化工具?我从来不需要visulizer。

巨大的文件支持 - UGS 使用常量内存! #302
所有者作者

您从 jtable 中得到的一件好事是它将
响应与命令相匹配。但我仍然在想同样的事情。

对于可视化工具,很多人将其用作预览工具。也许我会
在可视化大文件时添加警告。

在 2015 年 12 月 26 日星期六,rugbymauri notifications@github.com写道:

真的需要 JTable 吗?
登录到控制台就足够了。

甚至是可视化工具?我从来不需要visulizer。


直接回复此电子邮件或在 GitHub
#302(评论)
上查看 。

巨大的文件支持 - UGS 使用常量内存! #302
贡献者

不管它值多少钱,我都不会错过这张桌子。IMO,机器状态指示器足以知道它是否保持缓冲区已满。

我正在查看分析器中的内容(针对 master,而不是这个分支),在我看来,一个主要问题将是滚动日志。我们需要确保 guy 得到修剪,并且理想情况下不会在滚动时不断创建新对象。当用激光运行我的机器时,GC 暂停很重要。

巨大的文件支持 - UGS 使用常量内存! #302
所有者作者

@philreindl这也是我的结论,普通 jTable 的设计并不是为了处理这么多数据而设计的。我尝试了各种各样的事情,但最终还是按原样离开了表格,但有一个复选框可以一起禁用它(默认情况下禁用它)。

在常量内存分支中,我已经有了文本日志,因此它不会增长超过一定数量,但对象仍在分配中。实际上,通过大量更改,我正在分配更多对象,因为我不再将所有内容都保存在内存中。一旦我解决了内存问题,我可能不得不再次测试流媒体性能。