To clarify, despite my disliking of inline imports, if it's the only way to get this kind of performance enanchements we should obviously do it... I feel we should understand what is going on though, if it's something we can fix more generally it will help also with all the other gi imports and it will avoid having to explain to activity developers that they need to be careful about what they import and where (especially because the issue might be unnoticeable on the hardware they are using).<br>
<br>On Friday, 8 November 2013, Daniel Narvaez  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We need to figure out why this is happening. It doesn't make any sense to me that avoiding the evince lib import would save 13 seconds. You could write a minimal test case, importing Gtk first, then time the Evince import. If it takes a long time in the testcase too you could strace it to see wtf is going on.<div>

<br></div><div>Local imports are a really bad idea for code maintenance.<div>
<br>On Friday, 8 November 2013, Gonzalo Odiard  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">There are many issues in Sugar regarding performance,<br>


but one of the more visible to the user is how much time the activities<br>take to start. This is not so evident in newer hardware,<br>but is important in XO-1. Is so important than by example, Peru will use sugar 0.94<br>



instead of a newer because o this.<br><br>I was doing some testing with the main activities:<br><br><a href="https://docs.google.com/spreadsheet/ccc?key=0As_jQJX0Me6XdDI2clFpX1FFRHhKMHVFZGkyakdST2c&usp=drive_web#gid=0" target="_blank">https://docs.google.com/spreadsheet/ccc?key=0As_jQJX0Me6XdDI2clFpX1FFRHhKMHVFZGkyakdST2c&usp=drive_web#gid=0</a><div>



<br></div><div>(These measures were done in a XO-1)<br><br>I first blamed to the port from gtk2 to gtk3 of the big regressions in performance,<br>but after looking with a little of detail, some can be solved easily.<br><br>



One of the arguments of the dynamic bindings was a better startup time due to not need initialize all the libraries until is needed use them. Then the import should<br>be lighter than before. Looks like that is not so true.<br>



<br>In the case of Write activity, I was able to reduce the start up in 7 or 8 seconds, just delaying the gstreamer initialization [1], and 1 or 2 seconds more delaying two other imports.<br><br>In the case of Browse activity, just delaying the import of Evince libraries to the moment when a pdf is opened, improve the start up time in 13 seconds (patch attached). The start up time is even better than the version in 0.94 <br>



<br>I think this work of identify big libraries used only in specific moments,<div>can be applied in other cases.</div><div><br></div><div>Gonzalo<br><br>[1] <a href="http://git.sugarlabs.org/write/mainline/commit/5dd843cf415d0c65e2927540225b0098f2b71cd0" target="_blank">http://git.sugarlabs.org/write/mainline/commit/5dd843cf415d0c65e2927540225b0098f2b71cd0</a><br>



[2] <a href="http://git.sugarlabs.org/write/mainline/commit/dba223f5749f510735692a06f246acee30ab50bf" target="_blank">http://git.sugarlabs.org/write/mainline/commit/dba223f5749f510735692a06f246acee30ab50bf</a><div><br></div>


</div></div></div>
</blockquote></div>
</div><br><br>-- <br>Daniel Narvaez<br><br>
</blockquote><br><br>-- <br>Daniel Narvaez<br><br>