Copy Page

You are not logged in. Any changes you make will be marked as anonymous. You may want to Log In if you already have an account. You can also Sign Up for a new account.

<h2>The characteristics of concurrent multi-module builds</h2>

The following article tries to discuss the effects of various concurrency scheduling options, seen in context of an 
actual build. For the sake of disussion in this article, the available concurrency always matches or exceeds the 
amount of schedulable work, if you're saturating your CPU then there's litte more to be gained, performance wise. 
All measurements done in this article is also based on ramdisk (tmpfs) based, models, meaning that IO in general is 
taken out of the equation.

<h2>Legend</h2>
The following abbreviations are used:
<table class="confluenceTable"><tbody>
<tr>
<th class="confluenceTh">Letter</th>
<th class="confluenceTh">Phase</th>
</tr>
<tr>
<td class="confluenceTd">C</td>
<td class="confluenceTd">compile</td>
</tr>
<tr>
<td class="confluenceTd">TC</td>
<td class="confluenceTd">Test compile</td>
</tr>
<tr>
<td class="confluenceTd">S</td>
<td class="confluenceTd">surefire</td>
</tr>
<tr>
<td class="confluenceTd">J</td>
<td class="confluenceTd">jar/install</td>
</tr>
<tr>
<td class="confluenceTd">X</td>
<td class="confluenceTd">blocked/unrunnable</td>
</tr>
</tbody></table>

This analysis tries to explain concurrency options seen in the context of one particular build. While this is definitely 
non-exhaustive, it suffices to illustrate the challenges/restriction encountered in making this /one/ build run optimally.

The module dependency graph is as follows

<img class="confluence-embedded-image" src="/download/attachments/230400682/dependencygraph.jpg?version=1&amp;modificationDate=1368939520479" data-image-src="/download/attachments/230400682/dependencygraph.jpg?version=1&amp;modificationDate=1368939520479" data-linked-resource-id="230565083" data-linked-resource-type="attachment" data-linked-resource-default-alias="dependencygraph.jpg" data-base-url="http://docs.codehaus.org" data-linked-resource-container-id="230400682" title="null > dependencygraph.jpg"> 
Figure 1: Dependency graph of project

<h3>My average project</h3>
I timed the actual phases of some other builds (my 2 test projects). These are fairly standard maven projects 
with lots of code and decent test coverage.

The interesting thing (not shown) is that the average time for the different lifecycle phases in a multi-module build 
did not vary much. Without loosing too much accuracy I could define an &quot;average&quot; module in my multi-module build. For mvn -o clean install my &quot;average&quot; module in my project spends
<ul>
	<li>30% compiling</li>
	<li>17% test-compiling</li>
	<li>49% in surefire</li>
	<li>4% in jar/install</li>
</ul>

That means there's less than the rounding error (&lt;1% left for all the other stuff).

To make things more interesting, I've transposed the (real) numbers from &quot;my average project&quot; onto the &quot;imaginary&quot; dependency graph seen in figure 1, to 
better understand what is happening. The figure has &quot;time&quot; along the X-axis, and shows the different modules along the Y axis.

<img class="confluence-embedded-image" src="/download/attachments/230400682/figure2.jpg?version=1&amp;modificationDate=1368939520465" data-image-src="/download/attachments/230400682/figure2.jpg?version=1&amp;modificationDate=1368939520465" data-linked-resource-id="230565082" data-linked-resource-type="attachment" data-linked-resource-default-alias="figure2.jpg" data-base-url="http://docs.codehaus.org" data-linked-resource-container-id="230400682" title="null > figure2.jpg"> 
Figure 2: Weave-mode run-time scheduling of modules in the average build, time along X axis

The interesting bit about this is that minor variations in the individual modules have little impact on the end-result: 
the figures are to-scale so if you can keep them visible at the same time you'll see the (lack of) difference.

<img class="confluence-embedded-image" src="/download/attachments/230400682/figure3.jpg?version=1&amp;modificationDate=1368939520456" data-image-src="/download/attachments/230400682/figure3.jpg?version=1&amp;modificationDate=1368939520456" data-linked-resource-id="230565081" data-linked-resource-type="attachment" data-linked-resource-default-alias="figure3.jpg" data-base-url="http://docs.codehaus.org" data-linked-resource-container-id="230400682" title="null > figure3.jpg"> 
Figure 3: Module E changes characteristics (becomes shorter than average), module Z follows scheduling

It's possible to draw a large number of graphs that have significant changes in invidvidual modules but no 
change on end-outcome.

<h1>The runtime-leaf-module issue</h1>
There's a given set of modules that are reactor-leaf-modules in the reactor dependency 
tree (Y and Z in this case). There is an additional set of runtime-leaf-modules that constitute the 
&quot;last modules to reach package/install&quot; in a concurrent build. If we assume that jar/install is mostly at very small 
phase at the end, we see that the race is all about reaching the packaging phase (between S and J in the figures <img class="emoticon emoticon-wink" data-emoticon-name="wink" border="0" src="/s/en_GB/3278/15/_/images/icons/emoticons/wink.png" alt="(wink)" title="(wink)" />)

Notable special cases:
<ul>
	<li>Forked executions can extend the reactor-leaf modules, altough this probably not relevant</li>
	<li>The war plugin is often quite heavy</li>
	<li>Integrations tests are not part of this equation. It is my impression that a lot of projects keep all integration tests in a single module, which basically means we're not going to be able to do anything for them</li>
</ul>

<img class="confluence-embedded-image" src="/download/attachments/230400682/figure4.jpg?version=1&amp;modificationDate=1368939520441" data-image-src="/download/attachments/230400682/figure4.jpg?version=1&amp;modificationDate=1368939520441" data-linked-resource-id="230565080" data-linked-resource-type="attachment" data-linked-resource-default-alias="figure4.jpg" data-base-url="http://docs.codehaus.org" data-linked-resource-container-id="230400682" title="null > figure4.jpg"> 
Figure 4: Same graph as figure 3, but with critical path runtime-leaf-module shown with red line

The graph shows the &quot;critical path&quot; in this build. Although it cannot be known up-front it will in effect always limit the total-time 
spent building this project.

<ul>
	<li>The red circle marks the &quot;hard floor&quot; of the concurrency potential. The dependency-ordered compile outputs is the single strongest force controlling timing of the build.</li>
	<li>It is arguable that this &quot;hard floor&quot; should be moved to after test-compile too.</li>
	<li>The test-compile phase has an inherent dependency on the &quot;compile&quot; phase of the same module. It is possible to see a &quot;TestCompile&quot; dependency graph that expresses the test-compile dependencies (allowing test-compile to run constrained only by test-jar depenedencies). But any performance improvement will only be gained if this can give improved scheduling along the critical path, and as such it will only provide an overall performance improvement equalling gains along the critical path). In other words, this scheduling would probably only save a few 100 ms for most projects.</li>
</ul>

Given this understanding, one could be tempted to look at a few other scenarios:
<ul>
	<li>Information could be profiled from previous runs that could be used to affect priorities in subsequent builds</li>
	<li>Before reaching the hard-floor, it's all about prioritizing the resources to get there. For all but the first module there's usually a lot of other runnable tasks all along this path</li>
	<li>After reaching the &quot;hard floor&quot;, the issue is mostly about prioritizing available resources to focus on 
reaching the packaging phase with all runtime-leaf-modules as quickly as possible ( all for one, one for all).</li>
</ul>

So it'd be possible to consider cross-module prioritization of threads/scheduling of tasks

<h1>Number of schedulable tasks</h1>

<img class="confluence-embedded-image" src="/download/attachments/230400682/figure5.jpg?version=1&amp;modificationDate=1368939520426" data-image-src="/download/attachments/230400682/figure5.jpg?version=1&amp;modificationDate=1368939520426" data-linked-resource-id="230565079" data-linked-resource-type="attachment" data-linked-resource-default-alias="figure5.jpg" data-base-url="http://docs.codehaus.org" data-linked-resource-container-id="230400682" title="null > figure5.jpg"> 
Figure 5: Number of schedulable tasks

<h1>Variations</h1>
<img class="confluence-embedded-image" src="/download/attachments/230400682/figure6.jpg?version=1&amp;modificationDate=1368939520402" data-image-src="/download/attachments/230400682/figure6.jpg?version=1&amp;modificationDate=1368939520402" data-linked-resource-id="230565078" data-linked-resource-type="attachment" data-linked-resource-default-alias="figure6.jpg" data-base-url="http://docs.codehaus.org" data-linked-resource-container-id="230400682" title="null > figure6.jpg"> 
Figure 6: first module in reactor dependency is critical path of execution

In this scenenario, the unit tests in the first module take a long time to complete.

<ul>
	<li>Overall concurrency is governed by reactor dependency graph</li>
	<li>There's little/no point in trying to schedule &quot;things&quot; our of order. We can just let everything from package 
onwards respect reactor dependency graph totally</li>
	<li>There's a number of crazy strategies I tried out, some of which I communicated to the dev list: 
 Most crazy optimizations only have any real use case if they're along the critical path, and then the effect is quite limited, 
 unless the optimization can affect /all/ of the potential critical paths that may arise, and even then it will be limited by the 
 number of runtime-leaf-modules.</li>
	<li>Profile information from previous runs could be used to influence priorities, but it looks mostly like it'd be 
maven telling different surefire-modules how much resources they can consume to reach the overall goal</li>
</ul>