<br><br><div class="gmail_quote">On Tue, Oct 30, 2012 at 6:44 PM, Sean Dague <span dir="ltr"><<a href="mailto:sdague@linux.vnet.ibm.com" target="_blank">sdague@linux.vnet.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The review to land the first entrypoints switch over in nova passed through review and hit jenkins this afternoon - <a href="https://review.openstack.org/#/c/11027/" target="_blank">https://review.openstack.org/#<u></u>/c/11027/</a> and Jenkins failed it on a timeout (exceeded 30 minutes to run).<br>

<br>
Clark helpfully suggested that the patch might actually have had a performance impact, so I've been collecting data, and it did.<br>
<br>
On a decent blade with a spinning disk.<br>
<br>
Before the change the nova unit tests are running: ~385s (385.158s<br>
, 386.089s on two runs to ensure no cache effects).<br>
<br>
After that change the nova unit tests are running: ~920s (919.561s, 922.514s)<br>
<br>
<br>
2.3 times slower.<br>
<br>
<br>
On my laptop (SSD) the effect is there, but not quite as dramatic: ~450s vs ~600s.<br>
<br>
So only 30% slower.<br>
<br>
<br>
While I get that in production, the class loading will disappear in the noise, that huge hit on the unit tests seems really problematic from a developer point of view. And a big problem from a CI perspective. Anyone have ideas on why this is such a huge hit, or thoughts on how to mitigate it?</blockquote>
<div><br></div><div>I haven't profiled it, but my guess is that the extra time is from scanning the entrypoints registry. That would, as you say, hardly matter when it is only done once on startup. Perhaps we need to cache driver loaded from the config outside of the manager (?) instance where it is used to avoid having to rescan the registry each time the tests set up the manager.</div>
<div><br></div><div>Doug</div><div><br></div></div>