问为什么基于java的编辑器通常很慢，因为据说java在预热阶段之后会很快？

EN

好吧，我知道大多数人会说"java现在并不慢，它只是一个缓慢的启动阶段“，但没有人能看着我的眼睛告诉我，使用netbeans、eclipse或jedit的响应性就像使用visual studio或textmate一样快，即使在运行了几个小时的”预热“时间之后。哦，我承认启动时间确实是个问题(止咳蚀)，但我在这里谈论的是一般的响应性。例如，当你调整窗口大小时，Jedit有一个很小的明显的延迟。

我认为，合理的比较应该是jedit (或任何基于java的文本编辑器)与TextMate、SciTE。

它真正归结为的问题是“如果netbeans/eclipse完全用C语言重写，具有相同的功能集，您会期望它具有与当前相同的性能特征吗？”

有什么想法吗？

还有一些观察结果：

这个简单的基于swing的编辑器1在调整窗口大小时会有非常奇怪的延迟，但滚动感觉非常灵敏。此外，使用netbeans时，当您开始调整大小时，直到您“停止”调整窗口的大小，它会绘制一个丑陋的黑色背景4.也许swing在窗口被拖动时拒绝进行任何刷新？

这是一个简单的swt简单的文本编辑器2。它对拖拽和滚动都有很好的响应。

这是另一个简单的(jface) swt编辑器3。它的大小调整得如此之差，我想这一定是个坏运气。我希望如此。

我还注意到，notepad和visual studio在刷新时(例如:在使用page down浏览非常长的文档时)往往会显示临时的白色"blips“。swt和swing应用程序似乎不会有这些额外的白点，所以我想知道它们是否有一些额外的内部缓冲或什么。这可能会导致感知上的小幅减速

5是一个相关的问题，但并不完全相同。

我目前的猜测，有点基于现有的答案/评论：

• Netbeans刚刚变得臃肿起来。也许有一些关于编辑java的东西让编辑器创建者走得太远了？也许他们出于某种原因没有优化他们的编辑器？
• java编辑器使用大量的内存，也许这使得L2缓存之外的东西？
• java编辑器编辑java，所以他们可能不得不不断地调用，比方说，slow.
• Netbeans，这会一次又一次地导致缓慢的启动惩罚？
• Swing是一个抽象层，覆盖在本机窗口小部件上，这可能会减慢速度。
• Swing有一个可怕的大小调整刷新策略，这使得它“看起来”使用客户端VM，所以它可能只是没有针对速度进行调整？(另请参阅6，其中包含一个指向另一个问题的链接，该问题的答案是一系列参数，您可以将其传递给netbeans以尝试并加快速度up).
• Swing/SWT在滚动过程中出现的伪像似乎比本机windows应用程序更少。也许这意味着他们有缓冲的“帮助器”来帮助避免工件，因为它不刷新immediately.
• Perhaps而导致感知到的缓慢Java没有巨型基准，所以可能它没有针对这种类型的加载进行优化？也许有一些隐藏的inefficiencies.
• Relatedly，也许java可以“变得”快，但不知何故编辑器的创建者没有有效地使用它(“核心库将为我节省speed-wise!").
• Maybe它只是”感觉“慢了，因为(至少netbeans)必须不断地调用新的java实例来运行调试器，等等，每个调试器都有自己的慢启动时间。”

谢谢！-收到-

1

2

3像java -cp一样编译/运行它。；swt\win32.jar；jface/* BasicEditor

4

5

6