Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tycho-dev] Fwd: [Bug 356888] Build performance drop with Tycho 0.13.0

I ran some tests on m2e-core build (20 modules, uses implicit target
platform). On my hardware, P2TargetPlatformResolver.resolvePlatform
takes roughly 17 seconds, or ~0.85 seconds per module. This is roughly
inline with numbers I remember from profiling jbosstools build couple of
years ago.

For the project mentioned in the first comment of 356888, going from
0.12 to 0.13 resulted in ~3.9 seconds build time *increase* per module.
Even if we assume target platform resolution did not take any time using
Tycho 0.12 for that project, we are still talking about >4x longer
resolution times compared to m2e-core.

My point is, resolution time increase may or may not be explained by the
"proper" use of slicer+projector in .target resolution. I believe it is
important to understand what happened before we attempt to mask the
problem by caching resolved .target files.


On 11-10-05 10:44 AM, Oberlies, Tobias wrote:
This is correct: both the "calculation of the implicit target
platform" (which I prefer to simply call "dependency resolution") and
the interpretation of target definition files roughly take the same
time. The difference to 0.12.0 however is that target file
interpretation and dependency resolution are done in two separate
slicer+projector calls. The reason is that only then it is possible
to get a "correct", Eclipse-like interpretation of target files.

The good thing about this independent resolver calls is that the
target file resolution always yields the same result, and hence can
be cached - unfortunately it currently isn't the case, but this
should be a quick win.

In the mid-term, there is even another optimization that we can do:
For eclipse-feature, eclipse-repository, and the future
eclipse-product packaging types, we could omit the dependency
resolution (i.e. stop after target platform computation) and this
which would save us more slicer+projector calls, making that version
even faster than 0.12.0. With done, this
shouldn't even be hard to do, but 353889 will still take me a while.


-----Original Message-----
From: tycho-dev-bounces@xxxxxxxxxxx [mailto:tycho-dev-bounces@xxxxxxxxxxx]
On Behalf Of Igor Fedorenko
Sent: Mittwoch, 5. Oktober 2011 15:25
To: Tycho developers list
Subject: [tycho-dev] Fwd: [Bug 356888] Build performance drop with Tycho


Do you mind explaining the difference between the new way of
interpreting .target files and calculation of implicit target platform?
  From what I understand, in both cases Tycho invokes slicer+projector in
about the same way, so I assume performance should be comparable too...
What am I missing?


-------- Original Message --------
Subject: [Bug 356888] Build performance drop with Tycho 0.13.0
Date: Wed,  5 Oct 2011 09:17:22 -0400
From: bugzilla-daemon@xxxxxxxxxxx
To: igor@xxxxxxxxxxxxxx
Product/Component: Tycho / Core

Tobias Oberlies<tobias.oberlies@xxxxxxx>  changed:

             What    |Removed                     |Added
             Platform|PC                          |All
              Version|unspecified                 |0.13.0
           OS/Version|Windows 7                   |All

--- Comment #8 from Tobias Oberlies<tobias.oberlies@xxxxxxx>  2011-10-05
09:17:18 EDT ---
There is one pretty obvious thing which we should fix first before
investigating further:
In Tycho 0.13.0, target definition files are (for the first time)
correctly. This requires some potentially costly calls to p2, so the
build is
expected to take longer with 0.13.0 than with 0.12.0.
Still, the current implementation is unnecessarily slow: In the loop which
computes the target _platform_ [1] for each module, the target _definition
file_ is resolved over and over again. We obviously need a cache for this.


Configure bugmail:
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are watching the assignee of the bug.
tycho-dev mailing list
tycho-dev mailing list

Back to the top