Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mylyn-dev] performance issues

I have noticed performance issues in a large monolithic web app (represented as just one eclipse project, with 50 or more jars in the classpath, including weblogic.jar etc.), but I suspect it's not directly Mylyn's fault and actually that project should probably be broken up into smaller modules.

However, what mostly seems to cause the slowness is when filtering is turned on in Package Explorer. It's a lot better with filtering off there, but if it's on then even scrolling a source file with the keyboard (with the cursor moving from method to method) becomes really slow as it causes methods to be added to the context.

This is with Mylyn 2.1 though, so I guess I'll try 2.2

Erkki

Mik Kersten wrote:

Hi Oleg,

I’ll answer Eugene’s post separately, but would like us to learn more about your performance problems. Mylyn is architected not to scale with workspace size, but with the size of your interaction history (we should be fine with today’s machine specs as long as your history doesn’t go over 100 years ;) This means that Mylyn should be happy with enormous workspaces, so long as your Eclipse is happy with that size of workspace. Fyi, my workspace is 238 large projects with substantial parts of the Eclipse SDK being built as source. What I could imagine happening with a very large workspace is that either we have a performance bug that we don’t know about, or that JDT is having trouble creating the Java model for your workspace. Mylyn requires the Java model for your task context to be available on demand as you navigate, as do other Eclipse facilities such as content assist and refactoring. Either way, we can work around this on the Mylyn end if you could point us at the problem. The easiest way would be to launch Eclipse with debugging and get a few thread dumps while there appears to be a Mylyn-related freeze. See:

  http://wiki.eclipse.org/index.php/Mylyn_Contributor_Reference#Debugging

From the thread dump we will be able to determine whether the problem is within JDT and could time out or make asynchronous some of those operations in order to preserve responsiveness. We don’t have any accounts of such problems to date so a stack trace is the best way to get this resolved in a timely manager. There are two other things you can do in the meantime:

1. Upgrade to Mylyn 2.2. It provides considerable performance improvements and additional laziness.

2. Increase the amount of memory that you launch Eclipse with (i.e., the -Xmx setting). JDT grows the size of its Java model cache proportionally to the available heap space, and if you have hundreds of projects open you will want that cache to be as large as possible.

Mik

*From:* mylyn-dev-bounces@xxxxxxxxxxx [mailto:mylyn-dev-bounces@xxxxxxxxxxx] *On Behalf Of *System Architect
*Sent:* Saturday, January 19, 2008 9:30 PM
*To:* Mylyn developer discussions
*Subject:* Re: [mylyn-dev] retire usage data feature in Mylyn


This proposal may be a benefit to the project - several developers complained that as soon as they load more'n 300-400 projects - navigation simply does not work - takes tens of seconds per action. If they disable Mylyn - they can work.

This also opens an interesting discussion - how well Mylyn scales. Did anyone have any experience with workspace sized like, say, entire Eclipse - with Equinox and JDT and everything as source projects?

Also interesting - is it possible to simulate such a huge environment for regression testing? I don't know what testing framework is applicable here as it involves generation GUI events. Did anyone tried TPTP? Abbot?

Kinds Regards,
Oleg
Eugene Kuleshov wrote:


 I wonder if it is time to retire the usage data feature in Mylyn?

Ian Skerrett announced [1] that Usage Data Collector feature [2] is now included with EPP builds [3]. That is making Mylyn's usage collector somewhat obsolete and since it haven't grown from the sanbox, it may make sense to retire it or merge its code (client or server side) with the EPP usage collector component.

 regards,
 Eugene

[1] http://dev.eclipse.org/mhonarc/lists/eclipse.org-committers/msg00468.html
[2] http://www.eclipse.org/epp/usagedata/index.php
[3] http://www.eclipse.org/epp/ganymede.php


_______________________________________________
mylyn-dev mailing list
mylyn-dev@xxxxxxxxxxx <mailto:mylyn-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/mylyn-dev

------------------------------------------------------------------------

_______________________________________________
mylyn-dev mailing list
mylyn-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mylyn-dev


Back to the top