|Re: [p2-dev] locking artirepos && performance|
Thanks for answering this quick, Ian!
I filed a bugzilla to track this(1), please let me know how to help get this resolved! :)
 = https://bugs.eclipse.org/bugs/show_bug.cgi?id=351944
From: p2-dev-bounces@xxxxxxxxxxx [mailto:p2-dev-bounces@xxxxxxxxxxx]
On Behalf Of Ian Bull
On Tue, Jul 12, 2011 at 11:09 AM, Haigermoser, Helmut <Helmut.Haigermoser@xxxxxxxxxxxxx> wrote:
Ciao @ll :
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?).
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.