Sat, 21 Aug 2010 01:11:30 -0400, Nick Sabalausky wrote: > "retard" <r...@tard.com.invalid> wrote in message > news:i4mt6o$ca...@digitalmars.com... >> Fri, 20 Aug 2010 17:37:18 -0400, Nick Sabalausky wrote: >> >>> "retard" <r...@tard.com.invalid> wrote in message >>> news:i4mrss$ca...@digitalmars.com... >>>> >>>> If you turn off the >>>> syntax check, Eclipse works just as fast as any native application on >>>> a modern desktop. >>> >>> I've tried eclipse with the fancy stuff off, and it's still slower >>> than C::B or PN2 for me. >> >> Of course it is. You're comparing apples and oranges. > > Fer cryin out loud, which one is it? Is Eclipse supposed to be "just as > fast as any native application", or is it "of course it's slower"? First > you say one, then you say the other.
I meant to say that Eclipse (perceivably) works just as fast as any (feature-wise equivalent) native application on a modern desktop. I recommended turning off some of the functionality to make it behave more like C::B and similar lightweight applications. The idea behind desktop Java applications is that since the application would run 100..100000 times faster than it needs to on a modern PC, a 2..100 times slower Java version is totally acceptable. Heck, I even use applications (with plugins) written in Ruby. Ruby has a lot worse VM that does not even do JIT compilation. To summarize: - the JIT causes horrible interactive performance right after startup (use of the client VM might help a bit. Oracle might also be working on a hybrid client/server VM) - the JIT and the GC cause noticeable delays, but only occasionally (use of the new low-latency GC and tuning the VM options might help here) - the execution performance IS worse, but the perceivable performance is often acceptable - application platforms such as Eclipse or Netbeans provide a very high level of flexibility, portability, and memory safety
