You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently most (all?) tycho Mojos synchronize on a static lock, effectively allowing only different goals to run in parallel.
Especially the (relatively) long-running compile and package mojos spend more time waiting for the lock than doing actual work in a build with 32 threads.
Maven only recommends that pessimistic lock pattern "if a mojo uses a known-non-threadsafe external dependency" [1].
AFAICS that's not the case. Removing the locks speeds up a mvn clean package -T 2C (=32) a lot: 18min vs 1h before.
See the attached comparison.
Apart from those two mojos, only the P2MetadataMojo blocks for some significant (but much less) time in our build. But there's a lot going on and I can't quite guarantee its threadsafety.
I don't have the time to dig deeper ATM, so I'll close this issue for now.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=571434
https://bugzillaattachments.eclipsecontent.org/bugs/attachment.cgi?id=285635
Currently most (all?) tycho Mojos synchronize on a static lock, effectively allowing only different goals to run in parallel.
Especially the (relatively) long-running compile and package mojos spend more time waiting for the lock than doing actual work in a build with 32 threads.
Maven only recommends that pessimistic lock pattern "if a mojo uses a known-non-threadsafe external dependency" [1].
AFAICS that's not the case. Removing the locks speeds up a mvn clean package -T 2C (=32) a lot: 18min vs 1h before.
See the attached comparison.
[1] https://cwiki.apache.org/confluence/display/MAVEN/Parallel+builds+in+Maven+3
The text was updated successfully, but these errors were encountered: