why are java based editors typically slow, given that java is said to be fast after a warmup phase?

Question

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-

[1] http://www.picksourcecode.com/articles/explan.php?id=6c9882bbac1c7093bd25041881277658&ems=9a0fa83125d48ab7258eab27754dd23e&lg=10

[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

[4] http://twitpic.com/4xi8ov

[5] Is Java really slow?

[6] is there a way to make netbeans use the hotspot server vm

Answer 1

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).

Answer 2

This doesn't directly answer your question but here's some more info regarding window toolkit benchmarks

It is hard to give a rule-of-thumb where SWT would outperform Swing, or vice versa. In some environments (e.g., Windows), SWT is a winner. In others (Linux, VMware hosting Windows), Swing and its redraw optimization outperform SWT significantly. Differences in performance are significant: factors of 2 and more are common, in either direction. Code written in C/C++ using the X library performs somewhat faster than code written in Java using SWT, with the speed-up being from 5% to 10%

Source http://pub.cosylab.com/CSS/DOC-SWT_Vs._Swing_Performance_Comparison.pdf

Answer 3

Perhaps java uses more memory typically (at least, in my experience it does, and the alioth benchmarks seem to agree...

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.

Answer 4

Perhaps you're confusing 2 different things:

• "java isn't slow these days, it just has a slow startup phase"

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 for hours of "warmup" time. Oh, startup time is definitely a problem (cough eclipse)

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?