Skip to main content

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

Hi Erkki,

We made some improvements to the performance of this in Mylyn 2.2, but even more are available in the latest 2.3 weekly build: http://www.eclipse.org/mylyn/downloads/ 

Could you try that out and let us know if the performance has improved?  We haven't yet profiled with something that included that many JARs in a single project.

Mik

> -----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



Back to the top