RE: [mylyn-dev] performance issues

["Mik Kersten" <mik@xxxxxxxxxxx>]

Hi Erkki,

If you are referring to how long it takes for a method to show up in a Package Explorer that's focused, that ~1s delay is by design.  We use on Eclipse's "post selection" mechanism to determine what populates the context model, and there is a delay built into that mechanism.  The reason we believe that this is an overall benefit is that it prevents mis-selections and actually helps performance overall by batching selections.  For example, as you type or page down through a file, a post selection event is not fired for each key stroke.  It's also more consistent with the way Eclipse does it's view linking.  However, if you are finding that it doesn't feel quite right, consider filing a bug since we could explore having the population of context be synchronized with "pre" instead of "post" selections.

Regarding performance of JDT, I don't know about the performance profile between a large set of small projects or a small set of large projects.  It seems that compilation speed would be similar, and a lot of what you feel as a user is the speed of the Java Model.  What we recommend when working on large projects is to use the Xmx setting to give Eclipse as much memory as you can, since the size of the Java model cache grows with the available heap space.  This is documented at:

http://wiki.eclipse.org/index.php/Mylyn_FAQ#What_is_Mylyn.27s_performance_profile.3F

Mik

> -----Original Message-----
> From: mylyn-dev-bounces@xxxxxxxxxxx [mailto:mylyn-dev-
> bounces@xxxxxxxxxxx] On Behalf Of Erkki Lindpere
> Sent: Wednesday, February 27, 2008 12:31 PM
> To: Mylyn developer discussions
> Subject: Re: [mylyn-dev] performance issues
> 
> I tried 2.3, but the same issue still remains (adding methods to the
> context takes about 1 second when filtering enabled in package
> explorer). Should I open a bug or not? Because the project is rather
> bigger than normal and perhaps shouldn't be one eclipse project.
> 
> Actually I underestimated the project size in my previous mail -- there
> are 122 jar files in the classpath! -- some of them rather big
> (weblogic.jar). The project itself has thousands of classes as well,
> plus lots of XML. Frankly, I don't think any IDE is meant to handle
> this
> and still be very fast.
> I'm assuming that Eclipse (JDT) generally prefers lots of smaller
> projects to a few big ones... is that true?
> 
> Erkki
> 
> Mik Kersten wrote:
> > 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
> >>
> >
> > _______________________________________________
> > 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