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
https://dev.eclipse.org/mailman/listinfo/mylyn-dev