Interesting enough, I had a couple of different conversations over the last couple of days on the topic of "What do we still need from Eclipse for it to be successful". The context of success is the areas I work in of course, the CDT user space and Linux and Embedded in particular. Here, as I've blogged many times before, we still face an up hill battle to get developers to use Eclipse for their IDE.
From what I can see, it seems to come down to performance and start up performance in particular. Our users can easily and very quickly bring up vi to edit their code, run make to do a build, and fire up gdb to debug. That's the workflow they are used to and their first reaction to being introduced to Eclipse CDT, which does a great job of wrapping this workflow, is "man that took a long time to start up."
Start up performance isn't all of the story. Many of the workflows in Eclipse are pretty foreign to them as well, but right now I'm focusing on the performance issue and whether there is anything we can do about it. I know there have been task forces over the years that tried to address it. I remember getting bugged about the CDT running at start-up. So if you have any information about the progress of those I'd be interested.
I guess to make the problem even more serious, we are getting compared with other IDEs, like Qt Creator and Visual Studio, which take maybe half the time or less to start up than Eclipse does. And it's hard to justify to potential customers and users why that's OK. It's something that's starting to get critical and we need to find an answer.
So, the challenge is, can we get Eclipse to start up in 3 seconds, about the most users will notice, a guideline I've used for other UI operations over the years. And it's not just an objective. It's time to start treating it as a hard requirement. People wonder why I'm a little negative on e4, this would be one of the reasons. My users need start-up performance addressed. And that will require a pretty radical change in thinking that will be at odds with many in the community.
But we need to start having the conversation. I'm looking forward to reading your comments. Please let us know what you think pro or con, or even potential solutions. The one I got from twitter that I like the most is rewriting Eclipse in C++. But I've said that before. Anything more practical?
The first step would be to get some hard data on what code gets executed at startup. Here is a tool that might help (haven't tried it lately, not sure if it still runs against 3.6): http://borisoneclipse.blogspot.com/2007/03/who-is-to-blame.html
ReplyDeleteIn Linux land recently there is a movement to Upstart system initialization daemon which deprecates old init. You can borrow some ideas like start-on-demand and parallel initialization from there.
ReplyDeletehttp://www.linux.com/archive/articles/57213
Certainly rewriting Eclipse in C++ does not solve the speed problem. There are crawling C++ apps out there. Eclipse is the fastest Java IDE on the planet, and faster than MSVC (written in C# and C++ before that). Java does not have the speed problem some still connect to it. It's just that Java code is sometimes badly written.
ReplyDeleteI think lazy initialization should be used more often. But other than that I have no clue where Eclipses needs the most time.
After checking Boris' link I got another idea where cycles might be wasted. Most, if not all Eclipse plugins use a bundle activator, and that Bundle activator derives from the AbstractUIPlugin hierarchy. Maybe the information provided by this base class could be used directly in the plugins and skip the activator (its not needed in the OSGi world anyway, use FrameworkUtil.getBundle(Class) if you want to know which bundle the class is from).
ReplyDeleteHi,
ReplyDeleteGenerally I use CDT for large project (.pdom file is something around 1GB). And I can say that startup performance is not important for me. General "working" performance is better than some other IDE's (including MSVC).
There are still some performance related issues:
- There is no way to "cancel" code completion. For example typing "::" will cause total freeze for ~1 minute and there is no way to cancel it by pressing "Esc" key or something like this.
- Eclipse tries to refresh workspace after each build. And this takes huge amount of time (and again, there is no way to disable it or enable for output directory only). There is bugzilla issue for this.
- Compiler output parsing should be on-the-fly.
I don't see how this relates to e4 because if you look at the e4-RCPs you see that the platform itself is able to quite fast.
ReplyDeleteMaking the platform code as small as possible is the best e4 can do, without as less abstraction, as less legacy code is the only thing the platform can do.
@Boris: thanks for the pointer. Profiling is definitely the next step.
ReplyDelete@Tom: if you are telling me e4 will solve this problem, then I'm sold. My fear is that it'll make this worse. But I'm waiting for a full Eclipse SDK running on e4 as a test example to see.
I'd love to see something like bootchart:
ReplyDeletehttp://www.bootchart.org/
or Michael Meeks' newer fork:
http://github.com/mmeeks/bootchart
for Eclipse. Heck, let's just bribe Michael to do some performance work on Eclipse :)
Although I cannot argue against performance improvements and certainly would appreciate a faster start up, I wonder if that is indeed a top priority.
ReplyDeleteDisclaimer1: I am a Java developer and have never used CDT.
Disclaimer2: I am truly trying to help (ie, I am not being defensive, even because I am not really related to the problems discussed here ;-)
A Java developer can probably adopt a similar workflow that you've described for C. And VI editing Java would open as fast as VI editing C ;-) But I don't know a single Java developer that does it after seeing what Eclipse can do. Why? Because even if takes 10x longer to launch Eclipse (which is not the case), after it is up and running, such a developer is at least 10x more productive.
Putting it in a simple way: if a longer start up is reason enough for people to stop using a program, I'd say that this program may be not that useful to them. Specially when they'd be using this program for hours, probably keeping it up for the entire day. So, would these developers really use Eclipse if it had a 1 sec start up?
IMHO, the real questions are:
- Would there be a set of non-implemented killing features that would convince these developer that Eclipse is an invaluable tool?
- Or could they be convinced if the existing features were polished to be even better (whatever "better" means ;-)
I was expecting someone to say that :). The truth of the matter is that the Java developer and the C/C++ developer have different environments, and, thus, different needs. We are getting beat up regularly by our paying customers on these issues, to the point where we are questioning whether jumping on Eclipse was the right strategy. So, yeah, it's a top priority for our community.
ReplyDeleteStart up performance is just the top of the list right now, the bizarre build and launch systems (bizarre by C/C++ standards) is right behind. The good news is that they love the advanced edit and source navigation features, but that's not a top priority for our users. Productivity in the basic workflows, start, edit code, build and debug are, and there are issues there with Eclipse.
And yeah, if we get those right, more people will use Eclipse. All? No. Because there will always be the crowd that learned vi, make, and gdb first and I'm don't think we'll ever be a "better" solution for them. But we need to get rid of pain points so that we limit the FUD these guys are creating.
Back when I made the switch from raw text editors, shell and gdb to CDT I've heard that argument more than once, indeed.
ReplyDeleteMy response always was (and probably will be): How often do you start it anyway?
The more credible complaint I've heard was about memory usage and response times (along the lines of what dion mentioned).
But in most situations the general improvements of workflow beat the overhead hands down, because do you seriously want to use grep (or even ack) to look for assignments or usages of struct members?
I certainly can't go back. Every time I have to (e.g. work remotely via ssh real quick) I get so annoyed that it's not funny…
Sure, launch times are the first thing a new user sees, but you can't sell them on that alone anyway.
Improve the runtime characteristics as much as you possibly can, memory usage and cpu time, that's the real battlefield.
You mention bizarre build systems: If that's already on your list, I would give that priority, really.
Sure, do some profiling and get the low hanging fruit out of the way if you are beaten regularly over startup time, but my guess is that you won't be able to do much about it. BundleActivators from all over the place will probably ensure that :(
Just working with the autotools and CDT can be a royal pain. To be fair, that's not really CDT's fault ;)
Anyway, of all IDEs I ever used for C development CDT suits my needs the best. Kudos.
(Ever tried to convince VS to build something from a Unix world?)
Very cool. Thanks Kay. And I agree. I use the CDT a lot for different projects I work on and I love where we've gotten to with it.
ReplyDeleteI just need to find a way to stop the FUD from those resistant to using Eclipse. That's what our business people are hearing, and it seems to be louder than the value statements they are making. Why that is is probably another story.
There probably will always be a crowd that you cannot convince. To bad for them.
ReplyDeleteFor the others, making it integrate well with what they do/use today goes a long way.
For example, I have many different workspaces for many different versions/feature branches of our products. If those were hard and/or time consuming to set up, it would be a deal breaker for me.
I'll not even go into the convenience of having Java and C code inside the same IDE (since one of our products is partly Java, partly C).
IMHO, if you can't sell them on value you won't ever sell them on anything. The next complaint you'll hear is that it uses too much memory (and most of that you absolutely can't do anything about, given that it's Java).
I just wouldn't kill myself trying to make it start up faster, it's an up-hill battle, esp considering most of the problems are well outside of CDT.
True. But if I don't sell them anything, and this isn't just a small handful of people, I don't get to work on open source. That's my motivation.
ReplyDeleteAnd I'm not limiting myself to CDT here, I want to understand the whole picture so we can make an educated decision going forward for all of Eclipse, or at least those who have the same needs.
I don't know about the status of CDT. But every time I have to switch to C++ development, I have to use the Microsoft IDEs. And they just cannot compare to the Eclipse (Java) IDE. Refactoring? Still only possible with 3rd Party plugins. Unit Testing? Huh? I would bet you could nicely integrate that with Eclipse CDT. Startup performance is no better with VC2005 on the same machine here, even worse. Response time in the MS IDE is slow compared to Eclipse.
ReplyDeleteBut maybe I should first try out the C++ Development process in CDT to understand what problems it has on the Eclipse Platform.
Doug, ok, I was under the impression you were focussing on CDT.
ReplyDeleteDon't get me wrong, I'm not opposed to have snappy software ;)
OTOH my job has me working on server-side software and there the equation is very different anyhow.
I'm starting to wonder what the underlying motives are for folks to claim startup time is the deal breaker, though.
I think it's worth the effort trying to find out the actual reason.
From my experience almost everyone will eventually be convinced by superb integration, because what do developers hate the most? Repetitous, manual labor, AFAICS.
I've even forced myself to use Emacs for that reason once upon a time ;)
Doug, which platform are you talking about ?
ReplyDeleteUnder Windows there is a prefetch, so if I start Eclipse the 2nd time, it is much faster.
So it is not so much an issue for me.
Also I noticed that most of the startup time was eaten by the virus scanner (on my company pc). They looked into each *.jar file/bundle during startup which slowed it down very much.
To be honest, I do not have problems with the startup time, but with the sometimes freezing ui of CDT. Examples have been mentioned before like codecompletion, compiler output, workspace refresh, crossreference parsing...
regarding startup time AFAIK VisualStudio is not that much faster (the enterprise version).
The free VisualStudio Express version very fast however.
cheers,
Berni.
@Kay: It's FUD. I know it's FUD. It comes from guys who are resistant to change, to move into the new world of IDEs and don't want to pay for them. I'm just trying to minimize their excuses.
ReplyDelete@Bernhard: I'm running on Linux. I'm seeing 6 second startup with a plain Platform opening to a resource perspective with no projects.
ReplyDeleteI'll be honest, I'm pretty sure the effort will be futile, but I need to find out for myself.
Hm have you considered -Xverify:none ?
ReplyDeletemy eclipse-cpp-helios-M3-win32.win32.x86
comes up in 6sec without that switch and in 3sec !!! with that switch. (project in ws is closed)
if everybody would switch to Java 1.6
http://dev.eclipse.org/newslists/news.eclipse.platform/msg64497.html
@Bernhard Merkle: Very cool, thank you. I'll give it a try and see if it changes the startup time.
ReplyDelete@Doug: How should e4 solve the problem that the whole world thinks that they component is the most imporant. I wanted to emphasize on the fact that you are probably blaming the wrong one for the long startup times.
ReplyDeleteThe best the platform can do is to be as small as possible. That's why I don't understand your comment on e4 because e4 code is smaller than 3.x
@Tom. I'm not expecting e4 to solve the problem, I just don't want to see it adversely impact the performance of the IDEs that we are building with Eclipse, especially as we go about trying to improve performances.
ReplyDeleteI agree with Marcelo. My top two development tools (in no particular order) are VI and Eclipse. They are two *different* tools. One is a text editor and one is an "Environment" (the E in IDE). When I need to make a small change to a file, I use VI. When I need an environment in which to work, I start Eclipse.
ReplyDeleteA more valuable comparison, IMHO, would be the "opening of a file in Eclipse" vs. the "opening of a file in VI". -- Take into consideration the support the underlying environment has in helping you find and manage that file too.
Just as I don't complain that VI is slow because I have to 1. Boot my machine, 2. log into linux, 3. navigate my directory structure and 4. type vi foo.txt, I should not compare editing in Eclipse to launching eclipse.
Having said all that, if we can improve the startup performance *GREAT*!, but is it the right measure of performance? What if we double the startup time (do more caching during startup), but increase the speed at which Eclipse runs (by 2x) ... would C/C++ be opposed to that?
I would not go down the road to compare with vi.
ReplyDeleteCompare with visual studio, netbeans, intellij, metrowerks codewarrior, x-coder etc.
in addition, it is NOT just about startup time, it is about productivity...
ReplyDeleteLets take a competition one team vi, one team eclipse CDT. Now develop a small application, e.g. with TDD. Write testcases first, do unit tests, make some refactoring, renaming, version control operations, etc.etc.
I do not believe that the vi team is faster and will finish the sprint as winner ... ;-)
One thing you said kind of jumped out at me:
ReplyDelete"Start up performance isn't all of the story. Many of the workflows in Eclipse are pretty foreign to them as well, but right now I'm focusing on the performance issue and whether there is anything we can do about it."
I suspect that making significant progress on start up performance will not be significant. Start up performance is a real issue mostly for folks who are not familiar with usage, and the real hard spots are when experienced users must deal with routine development operations that fall off the performance cliff. If you look at competition, Qt creator, Win VS, or {emacs, vi}/gcc/gdb for example, you are looking at products that, one way or another, have the benefit of many years of performance tuning activities which would be extremely expensive to duplicate with CDT. As with any interactive engineering facility, users learn how to finesse things, such as product performance, which interfere with productivity; I think it's this sort of behavior that Eclipse CDT should try to facilitate.
My recommendation is to focus on discovery and facilitation of what you call the "foreign workflows", possibly with some sort of workflow graph concept, and to provide means to avoid or defer start up tasks that would be optional or irrelevant for a given workflow. For example, there could be one workflow template for setting up a project and building metadata, a second for editing source files and getting clean compiles, and a third for running the debugger or unit tests on the changed source files. 3 second startup is probably unnecessary for the first and third cases.
@Bernhard,
ReplyDelete-Xverify:none doesn't apply to Mac OS X systems. It will fail to create the JVM if this is in the eclipse.ini, though an argument could be made for other operating systems.
However, -X args (in general) are non-standard, and so vary from VM to VM. It's not clear whether putting that in a OS-wide setting would be a good idea.
Alex
Just my two cents: The startup time is the main reasons why I don't base my projects on Eclipse RCP. Waiting a minute just to run a test is prohibitive.
ReplyDeleteIf I go to Window:Preferences:General:Startup and Shutdown
ReplyDeleteand uncheck all the stuff I do not usually need my startup goes from 24 seconds to 10 seconds (I have a Java EE setup with the CDT installed on top as I do both C and Java).
I just did this now.
Maybe eclipse could notice if a started plugin is not used and then delay it's start up next time if it is not used in 3 sessions...many users (like me) will just use Eclipse just as it comes out of the box until
they get inspired by an article like this :-).
Will the JVM not get persistant JITing at some point
so unchanged JARs are already machine code?
Hi,
ReplyDeleteI do not mind at all Eclipse startup time; what bothers me more is that project references seem to be broken, that I get a full build every time I do a build, and that I cannot debug (Eclipse silently refuses to do it).
If I am missing something basic I would appreciate being pointed to a good tutorial for the Eclipse version I am using (latest as of Feb 2010) because so far I found none.
Doug,
ReplyDeleteI've debated for a few weeks whether or not to respond to this topic, but my frustration with Eclipse CDT to date has reached a bit of a boiling point.
We've done a lot of talking about startup times, during-regular-use performance, and so forth. What I think we should focus on are basic features that simply do not work in a user-friendly way right now.
I'm going to focus on my feelings about the Indexer. To start with, I'm using the latest and greatest downloads of every thing, with all updates installed. Coincidentally, I'm also using a completely fresh install of an operating system with all updates installed (Suse Enterprise Server 10.2).
With all due respect, the Eclipse CDT Indexer is a complete piece of trash. Since many, many of the rest of the features of any respectable IDE depends on a solid indexing of the source code, this is a grave concern. Here is what I have to do to get the indexer to work:
1) create a completely separate build configuration that only includes the *current* project on its list of includes
- note, this should be an option that the Indexer allows with a simple check-box ("Index Only Current Project"), without creating the additional build configuration. Moreover, this should be the *default* setting.
2) if *any* other projects from my workspace are included, the indexer will crash (heap overflow), and Eclipse recommends restarting the workspace.
3) I also have to go to the Workspace Settings and turn *off* automatic indexing. If I don't turn it off, it will re-index all the time, and crash Eclipse each-and-every time.
4) During indexing, the rest of the system is unusable!
- Note, this is a 32GB + Dual Quad Core Xeon (2.66ghz) 5500s. Quad SAS drives on an Adaptec 5405 RAID. I can build the entire Boost library in about 5 minutes. I can build my entire set of projects in about 1 minute. Machine performance is a non-issue here.
- if the compiler can use all 8 processor cores to do those builds, and in the meantime I can write code with Eclipse and otherwise use my machine, the Indexer shouldn't freeze all of Eclipse when it kicks off.
What's worse, there is a serious bug in the Indexer Settings Property Page.
- if I click "Apply", even after I have just selected to *not* automatically index, the Indexer starts and regularly crashes Eclipse
- if I click Ok, even after I have just selected to *not* automatically index, the Indexer starts and regularly crashes Eclipse
So even if I'm trying to escape the Indexer, I still have to endure it crashing Eclipse with regularity. Without an indexed project, the rest of the features of Eclipse are worthless to me (code completion, hitting F3 to go to a referenced class, etc).
I feel this needs a serious addressing. If you'd like some recommendations, I can perhaps dig into the code and help out.
Oh yes. The CDT indexer is running very slow. Especially when reference one project with many others.
ReplyDeleteI am using CDT with some big projects with many references. And even with 16G memory with 4 cores Xeon processor, then "fast index" still working too slow. The only way to me to make it faster is to remove other source code reference.
So I guess this is the worst part of CDT, and I am not sure the algorithm for multiple PDOM files has issues.
The other IDE may not be accurate parsing as CDT, but they do running fast, and this is one key for developer's continuous thinking. To me, each time when I save a file, then I need to wait 30-120 seconds before I can do any other things. Just too bad.
Hope this can be resolved by CDT profiling and optimization.
You can easily solve Eclipse indexer crashing problem by modifying memory settings in /etc/eclipse.ini, changing:
ReplyDelete-XX:MaxPermSize=256m
-Xms40m
-Xmx384m
to:
-XX:MaxPermSize=1024m
-Xms512m
-Xmx1024m
as described at: http://docs.oseems.com/general/application/eclipse/fix-gc-overhead-limit-exceeded
I must say I agree with the author.
ReplyDeleteAfter using eclipse and CDT for many years I am getting tired of the igored performance and stability issues. As a consultant I very often see how customers either identify and address such issues, focusing on lean and verifiable designs and processes and succeeding as well as growing _OR_ ignoring crucial metrics and slowly die!
I really like the functionality in eclipse/CDT. It's more and more to the point and adds high productivity value... when it works! But to be honest, so does other IDE's.
I for one, just to add what I think is a valid perspective, would love to wotk with contribution to a product that successfully apply high order TDD/BDD and a lean CI. (Yeah, I did say 'high ordger' for a reason :-)
What a perfect way to share know-how above just Java-coding-trivias....