"One of the new additions of Fedora Core 4 is a natively compiled version of Eclipse. I took it for a spin to see if it is a suitable replacement for 'regular' Eclipse."
Post a Comment
Member since:
---
Member since:
2005-07-06
Member since:
---
Member since:---
Member since:2005-07-18
Member since:
---
"VS.NET opens in two seconds on my quite slow laptop. Huh?"
"Were you opening a project with over 250,000 lines of code?"
I work with VS.NET on a daily basis on a project that has over 300,000 lines of code. It takes close to a minute to open on my laptop with a 1.6 pentium-m with 512mb of RAM. So I'd say that it's not unreasonable for eclipse to take about a minute to open a similiar size project.
Member since:
2005-07-06
One glitch I immediately noticed on my install: the menus at the top of the window go: "File Edit %Refactoring.menu.label Source Navigate..."
BTW, I put some notes on using native eclipse on this little faq here:
http://www.simisen.com/jmg/pmwiki/pmwiki.php?n=Main.GNUJavaOnFedora
If anyone has any juicy tips to add, please comment. 
Member since:
---
Member since:
2005-08-07
- FC4's version of Eclipse is not a fork, it simply adds ahead-of-time compiled versions of many jar files for faster use with gcj.
- FC4's version is based on a milestone build of Eclipse 3.1. Now that 3.1 is out, it should be available soon as an update to FC4.
- The menu item bug (Refactoring.menu.label) was a bug in the pre-release version of CDT included in FC4.
- Eclipse has its own built-in Java compiler (also available as ecj), which is 1.5 capable.
- If you get the upstream version of Eclipse on FC4, you may want to also download a commercial Java VM, to avoid running eclipse fully-interpreted using gij (slow!)
Member since:2005-07-12
> The first reason is called "Java" and the second reason is called "GNU". Java is a slow language and the GNU Compiler Collection is a slow compiler that generates slow code. Since this so-called "native compiler" is just a Java frontend to the GNU Compiler Collection, the resulting code is code generated by a slow compiler from a slow language, and as such it is - you guess - slow.
Hmm... I was taught in my CS101 class (quite a few years ago) that languages aren't slow or fast. It's the implementation that's slow or fast. Maybe that fundamental concept has changed. :-)
Member since:2005-07-06
>languages aren't slow or fast. It's the implementation that's slow or fast.
A simplification at best.
If the language contains complex inefficient stuff in its definition: GC, call-by-name, dynamic type, 'open-classes' etc.., then the implementations will be likely slow because they will have much more work to do, so the language is slow.
Member since:2005-07-06
If the language contains complex inefficient stuff in its definition: GC, call-by-name, dynamic type, 'open-classes' etc.., then the implementations will be likely slow because they will have much more work to do, so the language is slow.
If the language doesn't do the work that means that the programmer will have to do it. This means that cost and time of software development using such languages is higher. This is why languages like java and C# is so popular.
In most situations it is simply cheaper to add a few megaherz to your computer than to pay for more development time. Somtimes paying for more development time is not even an option as the reality where the finished program is supposed to be used changes, and with it the needed specifications.
Member since:---
There are certain things that can make a language faster or slower than another, although you could argue that its just an implementation. For example, Java does bounds checking every time you access an array. The code generated by that is obviously going to be slower than C code which doesn't check to make sure the pointer is valid.
Member since:---
Of course, on the other hand some people would argue that java is more efficient because it allocates and deallocates larger chunks of memory at a time. This can lead to unresponsive apps, but in many cases a garbage collector can reduce the total amount of time spent managing memory.
Member since:
2005-07-06
Eclipse is a very poor design for performance. The way extensibility is handled, the way files are handled, etc., all add up to make for slow performance.
Even if Eclipse were written in C and compiled with the Intel C compiler, it would not be a speed demon. It just is not architected for performance but rather for IBM's rather perverse extensibility paradigm. I say perverse because it is very easy to make an Eclipse system that does not work because of mutually incompatible extensions. There are endless state management bugs in Eclipse and it is doubtful they will ever be fixed.
While Eclipse has a lot of features, it no joy to use if you want a fast IDE.
Member since:
---
Eclipse is very fast under Windows, moderately fast til slow under GTK2 and dog slow on a mac.
The main problem is the underlying graphics toolkit and how good SWT can handle it.
The main design issue Eclipse or the SWT has, is that the SWT is tailored heavily towards the Win32 API once an API goes further away from that one, speed problems arise.
GTK2 for instance for a long time had the issue, that the SWT needed a component Z order, but GTK2 did not have one, thus eclipse had to emulate the missing constructs via weird helper constructs.
I just wonder if a SWT to Swing port might help out in those cases, since Swing nowadays blows GTK2 away and is reasonably fast on a Mac (definitely faster than the Carbon-SWT IBM uses)
The above mentioned plugins architecture speedwise is a non issue nowadays it has gone through 5-6 revisions and IBM has no problem to break the APIs in between major versions, if it helps things out, and you can see that already in Eclipse 3.1 which is significantly faster than 3.0 although the UI side of things basically has not changed too much.
Member since:2005-07-06
Member since:
---
I have been using Eclipse since 2.0 on Windows, and one of the reasons it made me switch from Netbeans was, that it basically had native UI speed (which netbeans did not back then), the other one was refactoring.
I have used Eclipse for projects which more than half a million lines of code.
The biggest problem I encountered, never was speed on Windows, it never was, although things have become faster in 3.1 speed on those projects was a no brainer in 3.0 as well.
The biggest problem was that sometimes speed dropped to non tolerable levels thanks to NTFS fragmentation due to too many project artefacts.
Rolling out a projekt took way over two minutes once and dropped down to seven seconds after a heavy defragmentation session.
However, speed is indeed an issue on non Windows platforms up to the level that it is intolerably slow on Macs...
Can you elaborate where you encounter the speed problems exactly, we might be able in here to nail the problem down.
Member since:
---
Eclipse tends to start with rather conservative memory assumptions nailing it down to 64MB, you have to up the mem to tolerable levels:
I usually run it with 512MB (with a myriad of plugins, and at least 3 tomcats running paralelly from it) but even upping it to 128MB helps tremendously:
C:eclipseeclipse.exe -clean -vmargs -Xmx512M
is my startup config, give it a try.
Member since:
---
Member since:
---
Depending on the plugins you need normally somewhat between 256 and 512. But if you go for the big iron server development, ram cannot be enough, but under normal circumstances 256-512 should be enough even if you have app servers running in eclipse (jdk 1.5 has helped there to a big degree because only the first program instance sucks up lots of ram, then lots of ram is spared via shared libs)
Most people who complain about speed issues in Eclipse usually run it under very conservative ram settings, while I never really had those and eclipse is as slow or fast as every other windows program and mostly has been.
Member since:2005-07-06
I tested Eclipse 3.1 with these options:
-vmargs -Xms256m -Xmx512m
And it is still rather slow. I have about 30 open files and there is a noticeable delay when I switch between files.
Overall 3.1 seems a slight bit faster than 3.0, but not very much. I am also running JDK 1.5.
Compared to Visual Studio 2003 which I run on the same machine, Eclipse 3.1 is not in same class of performance. For my next test, I am going to look at IntelliJ 5.X and Netbeans 4.X. I hope there is some Java IDE that is not hobbled.
Member since:
---
Switching between open files works instantly here
eclipse more or less behaves like a native app.
(Pentium-M notebook with one gig of ram, eclipse nailed down to 512 with myriads of plugins installed)
btw. to the ram issue, here is an interesting article:
http://blog.exadel.com/?p=9#more-9
Member since:2005-07-06
I don't know why it is slow. For some reason I remember under a much older Eclipse 2.X the UI seemed speedier.
My machine is powerful - dual Opteron, 4GB RAM, 15K U320 SCSI drives. For most things, it screams.
However, the Eclipse 3.X series just doesn't seem to work smoothly or quickly.
I even followed the advice in the Exadel blog and it did not make any difference.
There may be some interaction between Java and my system that just doesn't work well. I will try some other tools and see if the slowness is there with all Java tools (meaning it is likely a JVM issue) or just Eclipse.
Member since:
---
switching from and to an open file takes a fraction of a second, basically the same speed I would get from tab switching on any other native app.
I dont know where the problem is, but I have never encountered it on any machine, and neither have I heard a complaint regarding this yet.
You get a slight delay at the opening of the first file because eclipse loads some plugins but afterwards everything is fast and pretty much the same speed as vstudio and other ides which hook themselves into the win32 api.
On other platforms there are speed issues, but on Windows, it is weird, that you encounter something like that. It should not be, maybe you should contact the eclipse devs on the eclipse newsserver.
Member since:
---
Member since:
---
Member since:
2005-07-12
Eclipse is a hog. It is dead-dog slow. It is a bloated mess. I've tried it several times, and I found it barely tolerable on newer, faster machines with lots of memory, and unusable on older machines (even causing lock ups), where other IDEs (most notably JBuilder) ran fine.
Unfortunately, Eclipse is becoming almost a de-facto standard in Java development, due to it's extensibility, IBM's marketing muscle, and being free.
I guess that Java devs are used to things being slow and bloated, so Eclipse being a huge, slow, resource hog is no skin off their backs. ;-)
Member since:
---
