-----Original Message-----
From: mylyn-dev-bounces@xxxxxxxxxxx [mailto:mylyn-dev-
bounces@xxxxxxxxxxx] On Behalf Of Erkki Lindpere
Sent: Friday, February 08, 2008 1:23 PM
To: Mylyn developer discussions
Subject: 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
_______________________________________________
mylyn-dev mailing list
mylyn-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mylyn-dev
