Slashdot Mirror


Fast Native Eclipse with GTK+ Looks

Mark Wielaard writes "The gcj team created a natively compiled build of the Eclipse IDE. The resulting binary starts up faster then with any traditional JVM since there is no virtual machine to initialize or slow byte code interpreter or just in time compiler involved. This means that gcj got a lot better since the last Slashdot story in December about gcj and Eclipse. Red Hat provides RPMs for easy installation. Footnotes has screenshots by Havoc Pennington of the Eclipse IDE with GTK+ widgets."

3 of 300 comments (clear)

  1. Re:Troll...Troll...Troll... by gumpish · · Score: 5, Informative

    And [Java] continues to be hyped, and is being used less and less, as the speed continues to hamper it.

    Java is still some 40 times faster than Python. As hardware speed continues to obey Moore's law, performance per clock cycle becomes less important. (For many areas of computing anyway.)

  2. GCJ performance is a myth. Benchmarks inside. by lokedhs · · Score: 5, Informative
    In general, GCJ compiled code is slower than the smae code running in the JVM. The only speed advantage comes from the startup times.

    Often the JVM will out-perform GCJ with a factor of 3. Check out the numbers on this page.

    I fail to see why people want to run a GCJ compiled evrsion of a development tool and run at at one third of the speed of the JVM, just in order to save a few seconds of startup time.

  3. Re:Memory Usage vs Eclipse Running in JVM by thimo · · Score: 5, Informative

    A quick test (using an Eclipse 2.1.1 from eclipse.org):

    Eclipse 2.1.1 with JVM
    - Second start: 13 seconds
    - Memory Eclipse: 80 MB
    - Memory JVM: 65 MB

    Eclipse 2.0.1 without JVM
    - Second start: 9 seconds
    - Memory: 96 MB

    The download page seems to indicate you're downloading an Eclipse 2.1.0 version, but the about dialog says 2.0.1. Which one is it?

    Cheers,

    Thimo (back to coding in Eclipse 2.1.1 :)

    --
    Avoid the Gates of Hell. Use Linux!