>Community Contributions and Eclipse Performance

>Eclipse Performance

Doug Schaefer’s “Eclipse vs Emacs, a unfinished battle” blog entry is something I think the committers and the foundation as a whole needs to keep in mind going forward. Particularly the following quote:

Eclipse is too big, too slow to start, and the UI too complex and unless we start addressing some of this, it’s still going to be a fight to get these users to buy into our story. There is a lot of value to the extensibility and integration story we are selling, but if the barrier to get Joe and Jane developer to even start the thing is too high, it’s no good.

This is not only for the developer, but also for those writing and using applications built on the RCP framework. The problem I see is that we as developers tend to have nice fast multi-core machines. However, the business community and the people using the products we are building still have single-core or older machines. It’s important when we are working on any platform code to consider what our potential end users are going to have. I’ve worked with Eclipse on a single core 1.2ghz system with 1GB of memory, and it is painful. And this was with eclipse 3.2 and 3.3, I don’t even want to try to run Eclipse 3.4 on the system. It would be great if the 3.5 version of eclipse was the same size memory and code wise, while adding and maintaining existing functionality.

Most of my user community works with large XML Schemas and XML files. When they have to wait 10 seconds or more on a single core system they aren’t happy. Also, if I want to provide ANT runtime ability or Java launching ability in my XML IDE, I have to include JDT. Unfortunately, 90% of the users of the product we built on eclipse don’t need or want a Java editor, they just want the ability to run some ant scripts, as well as work on their XML files. While eclipse has a lazy loading feature, it doesn’t necessarily unload something once it’s been loaded. So accessing a particular class in the JDT to launch an ANT script could cause significat portion of JDT functionality to be loaded as well.

In general as people wrap up 3.4, I hope that peformance will be a big planning item going forward with 3.5

Community Contributions

There has been a lot of chatter in various blogs about getting the community more involved, how hard it is to get a contribution added, how can you help influence the features implemented, etc. These are all issues I’ve experienced over the last couple of years as both a community users, a sometimes contributor, and as a part-time “unpaid” committer. Truthfully, there are too many hoops to jump through from a community members stand point. I’ve been on the receiving end of bugs reports going unanswered, patches or suggestions rejected out of hand, and planning that really isn’t very open. However, I’ve also been involved with projects in eclipse where I’ve had the opposite occur as well. EMF and PDE are two projects where I’ve had very good response rates and communication. They really should be commended for how quickly they respond to issues and request for enhancements.

The point that has been made about there aren’t enough bodies to toss at the problem. It’s been my experience over the years that you never solve a software problem by just tossing more bodies at it. Smaller teams seem to work best, but it is all in how they prioritize and organize themselves. While I can respect the need for IP cleanlyness and being conservative on what is accepted into the code base, it is also very discouraging for an outside user who has worked to fix an issue to have it rejected or marked “WON’T FIX” without some sort of explanation of why it won’t be fixed, or why the patch can’t be contributed.

I’m not sure how to fix the prioritization of features and bugs. I don’t think there is a nice clean way to do it that will meet everybody’s needs. However, I think what each project does need to do is eat it what it creates. My day job is working with various XML specifications. I’m also a part-time committer on the XSL Tooling project. I eat what I create in the way of code and features I put into the XSL Tooling project. If something isn’t working, it’s going to affect my ability to do my job. It’s one of the reasons I think JDT is so good, the developers use what they create themselves. If a corporation is paying for a committer to work on source code for eclipse, how likely is it that person actually uses what they create to do their job? I would guess maybe half, but that may be generous.

To me the community feedback and requests from the non-paid users and developers of eclipse is just as important as the companies that are paying programmers to write code for eclipse. If a community user is having problems, and they have sent a reproducable bug report, then I think it deserves higher consideration than a feature request from another source. The problem with waiting to triage a bug or respond to it several years later is that the person that reported it probably gave up on it a long time ago. We as committers need to make addressing these issues a top priority, otherwise, the user community feels like we don’t care.

Unfortunately, I don’t have the answers on how to fix this, but it is an issue that is of concern. I’m glad to see that Eric Rizzo brought the topic up for discussion, and that the community is continuing the discussion. How we address this will be important, as we can build all the great features into e4 we want, but if we continue with the same attention to the community that we have we are going to be repeating the same issues again.

This entry was posted in eclipse. Bookmark the permalink.

5 Responses to >Community Contributions and Eclipse Performance

  1. Ed Merks says:

    >David, as far as I’m concerned, you’re one of the pillars of the community. I enjoy reading your blogs and I appreciate the contributions you’ve made to EMF’s quality simply by taking the time to report problems.I can’t agree enough with your premise that we ought to fix our darned problems before we go off creating new ones by implementing new features! It might not be glamorous and it might not be fun, but it’s the right thing to do for countless different reasons.Public scrutiny is a valuable tool in the glass house that is Eclipse. May the critics have their say and may they too live in a glass house that’s open to scrutiny. And may we all become contributors toward a common goal…

  2. David Carver says:

    >Ed thanks. The funny thing is this isn’t just a problem with eclipse and the way we do things, but various standard organizations run into the same problem. How they address it is the difference between a good standard and bad one.Bob Sutor gives a a good presentation on this topic.

  3. >Its highly informative. I would be visiting your blog hereafter regularly to gather valuable information. http://www.2daybiz.com

  4. >Hi i am new bee here. I seen the information above it ill be more useful for me, its to good information to see in you blogs. šŸ˜‰ Job Site Search Engine Script

  5. kristinawils says:

    >Great post and very well written, that will really help you to learn Web Design, web development and SEO Strategies to help businesses web design company . You can find out many useful information about web design, seo and his work by visiting his blog and I Just wanna say thanks you for the information you have shared.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s