Thanks for answering this quick, Ian! :) The performance issue stems from the check for modifications, say a repo is asked a 100 times for artifacts (getArtifactDescriptor(key)), than 100 times the file on the network share is accessed and checked for its timestamp, in my test case this takes 40ms each time, which sums up to 4 secs just for this small example...
I filed a bugzilla to track this(1), please let me know how to help get this resolved! :) HTH, Ciao, Helmut [1] = https://bugs.eclipse.org/bugs/show_bug.cgi?id=351944 From: [email protected] [mailto:[email protected]] On Behalf Of Ian Bull Sent: Tuesday, July 12, 2011 8:48 PM To: P2 developer discussions Subject: Re: [p2-dev] locking artirepos && performance On Tue, Jul 12, 2011 at 11:09 AM, Haigermoser, Helmut <[email protected]<mailto:[email protected]>> wrote: Ciao @ll : Just debugged a huge performance problem in my installer over here. Calculating the required disk space (~2gig) took 120 seconds, rather than the usual < 2 seconds. Recently adopting 3.7 made my suspect new features to maybe be used incorrectly in my code, started debugging in that mind set... Turns out the big performance bottleneck is the simple arti repo. What it does is reread artifacts.xml each time a single call to "getArtifactDescriptors" or like methods is made. My location is read only (network share) and somewhat slow, so that explains why this bug was exposed in such a drastic fashion... It should do an 'up-to-date' check and only re-load the file if it has changed. Maybe across a network share this is not the case (timestamps maybe?). (See SimpleArtifactRepository#doLoad()). This seems like a really huge problem to me, can you guys fix this even on the 3.7 stream? I'm of course willing to contribute to the fix, by filing a bugzilla or whatever you guys want me to do, but I wanted to publish the problem here as well since I saw a bunch of locking-related messages before and thought maybe there was something I could do different in my code to work around the problem (-Declipse.p2.internal.simple.artifact.repository.locking=false did not work since that is only used in one of the two constructors of the simple arti repo)... The -Declipse.p2.internal.simple.artifact.repository.locking=false instructs p2 whether to 'lock' or 'not lock' the repository when writing. That is separate (but related) to cache invalidation. The fact that you are not reusing the cache seems like the real problem. I'm pretty sure, we can do something for 3.7.1. Please file a bug and CC me. Cheers, Ian TIA, Ciao, hh _______________________________________________ p2-dev mailing list [email protected]<mailto:[email protected]> https://dev.eclipse.org/mailman/listinfo/p2-dev -- R. Ian Bull | EclipseSource Victoria | +1 250 477 7484 http://eclipsesource.com | http://twitter.com/eclipsesource
_______________________________________________ p2-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/p2-dev
