为什么基于 java 的编辑器通常很慢，因为据说 java 在预热阶段后很快？
好吧，我知道大多数人都说“现在 java 并不慢，只是启动阶段很慢”，但没有人能直视我的眼睛并告诉我使用 netbeans 或 eclipse 或 jedit 的响应速度就像视觉一样灵敏。工作室或发短信，即使是在跑了几个小时的“热身”时间之后。哦，启动时间绝对是一个问题（咳嗽日食）我承认，但我在这里谈论的是一般响应能力。例如，当您调整窗口大小时，Jedit 会出现明显的小滞后。
我认为，合理的同类比较是 jedit（或任何基于 java 的文本编辑器）与 TextMate、SciTE。
它真正归结为的问题是“如果 netbeans/eclipse 完全用 C 重写，具有相同的功能集，您是否期望它具有与当前相同的性能特征。”
有什么想法吗？
还有一些观察结果：
当您调整窗口大小时，这个简单的基于摆动的编辑器 [1] 有非常奇怪的滞后，但滚动感觉非常灵敏。另外，使用 netbeans，当您开始调整大小时，直到您“停止”调整窗口大小时，它都会绘制丑陋的黑色背景 [4]。也许在拖动窗口时 Swing 拒绝进行任何刷新？
这是一个简单的 swt 简单文本编辑器 [2]。它对拖动和滚动都非常敏感。
这是另一个简单的 (jface) swt 编辑器 [3]。它的大小调整得如此糟糕，我想这一定是一个糟糕的侥幸。我希望。
我还注意到，记事本和 Visual Studio 在刷新时往往会显示临时的白色“斑点”（例如：在很长的文档中使用向下翻页时）。 swt 和 swing 应用程序似乎从来没有那些额外的白色斑点，所以我想知道它们是否有一些额外的内部缓冲或其他东西。这可能会导致小幅放缓，从感知角度来看
[5]是一个相关但不完全相同的问题。
我目前的猜测，基于现有的答案/评论：
- Netbeans 刚刚变得臃肿。也许编辑 java 的过程中有些东西让编辑器创建者变得太过分了？也许他们出于某种原因没有优化他们的编辑器？
- Java 编辑器使用大量 RAM，也许这会使内容远离二级缓存？
- Java 编辑器编辑 java，所以也许他们必须不断地调用 javac，这每次都会导致启动缓慢？
- SWT 是本机小部件的抽象层，这可能会减慢速度。
- Swing 有一个糟糕的调整大小刷新策略，这使得它“看起来”很慢。
- Netbeans 使用客户端虚拟机，所以也许它只是没有针对速度进行调整？ （另请参阅 [6]，其中包含另一个问题的链接，其答案是您可以传递给 netbeans 的大量参数，以尝试加快速度）。
- 与本机 Windows 应用程序相比，Swing/SWT 在滚动期间的伪像似乎更少。也许这意味着他们有缓冲“助手”来帮助避免伪影，从而导致感知缓慢，因为它不会立即刷新。
- 也许 Java 没有巨石基准，所以也许它没有针对这种类型的负载进行优化？也许存在一些隐藏的低效率。
- 与此相关的是，也许 java 可以“变得”更快，但不知何故，编辑器创建者并没有有效地使用它（“核心库将节省我的速度！”）。
- 也许它只是“感觉”很慢，因为（至少是netbeans）必须不断调用新的java实例来运行调试器等，每个实例都会有自己缓慢的启动时间。
谢谢！ -roger-
[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 真的很慢吗？
Ok, I know that most people say "java isn't slow these days, it just has a slow startup phase" but nobody can look me in the eye and tell me that using netbeans or eclipse or jedit is as responsive as say, visual studio or textmate, even after running for hours of "warmup" time. Oh, startup time is definitely a problem (cough eclipse) I'll admit, but I'm talking general responsiveness here. Jedit has a small noticeable lag when you resize windows, for example.
A reasonable apples to apples comparison would, I think, be jedit (or any java based text editor) versus TextMate, SciTE.
The question it really boils down to is "if netbeans/eclipse were rewritten entirely in C, with the same feature set, would you expect it to have the same performance characteristics as it currently does."
Any ideas?
And a few observations:
This simple swing-based editor [1] has very odd lags when you resize the window, but scrolling feels quite responsive. Also, with netbeans, when you start resizing, until you "stop" resizing the window it draws an ugly black background [4]. Perhaps swing refuses to do any refreshes while the window is being dragged?
Here is an simple swt simple text editor [2]. It is quite responsive to both dragging and scrolling.
Here is another simple (jface) swt editor [3]. It resizes so poorly I think it must be a bad fluke. I hope.
I've also noticed that notepad and visual studio tend to have show temporary white "blips" when they refresh (ex: when using page down through a very long document). swt and swing apps don't seem to ever have those extra white blips, so I'm wondering if they have some extra internal buffering or something. This could cause a small slowdown, perception wise
[5] is a related, but not quite the same, question.
My current guesses, based a little on the existing answers/comments:
- Netbeans has just become bloated. Maybe there's something about editing java that makes editor creators go overboard? Maybe they don't optimize their editors for some reason?
- Java editors use tons of RAM maybe that keeps things out of L2 cache?
- Java editors edit java, so maybe they have to keep constantly calling out to, say, javac, which incurs the slow startup penalty over and over again each time?
- SWT is an abstraction layer over native widgets, which maybe slow things down.
- Swing has an awful resize refresh policy, which makes it "appear" slow.
- Netbeans uses the client VM, so maybe it just isn't tuned for speed? (see also [6] which contains a link to another question with an answer that is a slew of parameters you can pass to netbeans to try and speed it up).
- Swing/SWT appear to have fewer artifacts during scrolling than native windows apps. Perhaps this means they have buffering "helpers" to help avoid artifacts, causing perceived slowness since it doesn't refresh immediately.
- Perhaps Java has no megalithic benchmarks, so maybe it is not optimized for that type of loads? Maybe there is some hidden inefficiencies.
- Relatedly, maybe java can be "made to be" fast, but somehow the editor creators aren't using it efficiently ("the core library will save me speed-wise!").
- Maybe it just "feels" slow since (at least netbeans) has to constantly call out to new java instances to run debuggers, etc., which each take their own slow startup time hit.
Thanks!
-roger-
[2] https://gist.github.com/972234
[3] http://www.java2s.com/Code/Java/SWT-JFace-Eclipse/BasicEditor.htm compile/run it like java -cp .;swt\win32.jar;jface/* BasicEditor
[6] is there a way to make netbeans use the hotspot server vm
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
要执行所有“动态”代码语法检查和突出显示，您基本上必须编写编辑器来理解（这意味着 lex、解析、类型检查、语法验证等）java 语言并验证文本内容在你从一个几乎空的课程开始到完成你的程序之间的每个中间状态。
另外，为了交叉引用完整性，您必须在内存中保存有关所有其他类的足够信息，以便您可以真正确保当您调用对象上的方法时，它确实存在于该“其他”对象上。
更不用说所有其他对项目进行索引的地方等等。简而言之
，它很慢，因为它做了很多事情，即使它所做的所有事情并没有立即被只关心项目的人所欣赏。屏幕上的字母（并非 IDE 的所有功能）。
To do all of that "on the fly" code syntax checking and highlighting, you basically have to write your editor to understand (that means lex, parse, type check, syntax verify, etc) the java language and verify the contents of the text editor during every intermediate state between you starting off with a nearly empty class and finishing your program.
Also for cross reference integrity, you have to hold enough information about all the other classes in memory so you can really make sure that when you call a method on an object, it really exists on that "other" object.
That's not to mention all of the other places where items are indexed, etc.
In short, it's slow because it's doing a lot, even if all of the stuff it is doing isn't immediately appreciated by a person who is only concerned with the letters on the screen (and not all the features of the IDE).
这并不能直接回答您的问题，但这里有一些有关窗口工具包基准测试的更多信息
来源 http://pub.cosylab.com/CSS/DOC-SWT_Vs._Swing_Performance_Comparison.pdf
This doesn't directly answer your question but here's some more info regarding window toolkit benchmarks
Source http://pub.cosylab.com/CSS/DOC-SWT_Vs._Swing_Performance_Comparison.pdf
也许您混淆了两件不同的事情：
JVM 作为字节码解释器运行，直到识别出热门方法，然后才将它们编译为本机代码。
对于 -server VM 配置（可能是硬件上的默认配置），方法不会被编译，直到方法调用/分支的数量 > XX:CompileThreshold=10000
即使运行后，比如说Eclipse，几个小时你认为你已经使用了相同的方法10,000次吗？ （尝试使用 -client JVM 标志启动 Java 编辑器。）
Eclipse 是一个大型 IDE - 它实际上不是一个基本的文本编辑器 - 也许它只是在启动时试图完成更多工作比一个基本的文本编辑器想要做什么？
Perhaps you're confusing 2 different things:
JVM operates as a byte code interpreter until hot methods have been identified, and only then compiles them to native code.
For the -server VM configuration (which may be the default on your hardware) methods are not compiled until the number of method invocations/branches is > XX:CompileThreshold=10000
Even after running, say Eclipse, for hours do you think you've used the same method 10,000 times? (Try starting your Java editor using the -client JVM flag.)
Eclipse is a large IDE - it really isn't a basic text editor - maybe it's just trying to accomplish a whole lot more when it starts up than a basic text editor is trying to do?
当任务要求程序分配比默认内存更多的内存时，请小心不要将默认内存分配的差异与内存使用的差异混淆。
正则表达式-DNA、反向补码、二叉树、k-核苷酸、mandelbrot 需要分配内存。
另请注意，某些程序是为多核编写的，并分配额外的缓冲区来累积来自多个线程的结果。
Please be careful not to confuse differences in default memory allocation with differences in Memory-used when the task requires programs to allocate more than the default memory.
regex-dna, reverse-complement, binary-trees, k-nucleotide, mandelbrot require allocating memory.
Also notice that some of the programs are written for multicore and allocate additional buffers to accumulate results from multiple threads.