为什么基于Java的编辑器通常很慢，因为Java在预热阶段后据说很快？
好吧，我知道大多数人说“Java现在并不慢，它只是有一个缓慢的启动阶段”，但没有人能看着我的眼睛告诉我，使用netbeans或eclipse或jedit与Visual Studio或textmate一样敏感，即使在运行了几个小时的“热身”时间之后也是如此。哦，启动时间绝对是一个问题（咳嗽日食），我承认，但我在这里说的是一般的响应能力。例如，当您调整窗口大小时，Jedit有一个小的明显滞后。
我认为，一个合理的苹果对苹果比较是jedit（或任何基于java的文本编辑器）与TextMate，SciTE。
它真正归结为的问题是“如果netbeans/eclipse完全用C语言重写，具有相同的功能集，你会期望它具有与当前相同的性能特征吗？
有什么想法吗？
还有一些观察结果：
当您调整窗口大小时，这个简单的基于摆动的编辑器[1]具有非常奇怪的滞后，但滚动感觉非常灵敏。此外，对于netbeans，当您开始调整大小时，直到您“停止”调整窗口大小，它会绘制一个丑陋的黑色背景[4]。也许秋千拒绝在窗口被拖动时进行任何刷新？
这是一个简单的swt简单文本编辑器[2]。它对拖动和滚动都非常敏感。
这是另一个简单的（jface）swt编辑器[3]。它的大小调整得如此之差，我认为这一定是一个糟糕的侥幸。我希望。
我还注意到，记事本和可视化工作室在刷新时往往会显示临时的白色“闪光点”（例如：在很长的文档中使用向下翻页时）。swt和swing应用程序似乎从未有过这些额外的白色光点，所以我想知道它们是否有一些额外的内部缓冲或其他内容。这可能会导致感知方面的小幅放缓
[5]是一个相关但不完全相同的问题。
我目前的猜测，基于现有的答案/评论：
- Netbeans刚刚变得臃肿。也许编辑java会让编辑器创建者过分？也许他们出于某种原因没有优化他们的编辑器？
- Java编辑器使用了大量的RAM，也许这可以使事情远离L2缓存？
- Java编辑器编辑java，所以也许他们必须不断调用，比如说，javac，这每次都会一遍又一遍地造成缓慢的启动惩罚？
- SWT是原生小部件的抽象层，可能会减慢速度。
- Swing 有一个可怕的调整大小刷新策略，这使得它“看起来”很慢。
- Netbeans 使用客户端虚拟机，所以也许它只是没有针对速度进行调整？（另请参阅 [6]，其中包含指向另一个问题的链接，其答案是您可以传递给 netbeans 以尝试加快速度的大量参数）。
- Swing/SWT 在滚动过程中的伪影似乎比本机 Windows 应用少。也许这意味着他们有缓冲“助手”来帮助避免伪影，导致感知到的缓慢，因为它不会立即刷新。
- 也许Java没有巨石基准测试，所以也许它没有针对这种类型的负载进行优化？也许有一些隐藏的低效率。
- 与此相关的是，也许java可以快速“成为”，但不知何故，编辑器创建者并没有有效地使用它（“核心库将在速度方面为我节省成本！”）。
- 也许它只是“感觉”慢，因为（至少netbeans）必须不断调用新的java实例来运行调试器等，每个实例都会占用自己的慢启动时间。
谢谢！-罗杰-
[2] https://gist.github.com/972234
[3] http://www.java2s.com/Code/Java/SWT-JFace-Eclipse/BasicEditor.htm 像java -cp一样编译/运行它。swt\win32.jar;jface/* BasicEditor
[5] Java真的慢吗？
