<div dir="ltr">Well, should be good know what is happening, but these are real timings.<div>I know the theory, and that probably was one of the reasons this was not done before,</div><div>but this was what I found. </div><div>
<br></div><div>Gonzalo </div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Nov 8, 2013 at 6:08 PM, Daniel Narvaez <span dir="ltr"><<a href="mailto:dwnarvaez@gmail.com" target="_blank">dwnarvaez@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Even more confused now...<br><br>The two evince imports you are moving doesn't even cause the dynamic library to be loaded, so they should have absolutely no performance impact.<br>
<br>That's the normal case in gobject-introspection, libraries are loaded lazily, when you try to use one of the functions.<br>
<br></div><div>Gtk is an exception because gtk_init is called automatically on import and there are probably other libraries that do something similar. Though I verified that's not the case for Evince by looking at the smaps.<br>
</div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On 8 November 2013 19:44, Gonzalo Odiard <span dir="ltr"><<a href="mailto:gonzalo@laptop.org" target="_blank">gonzalo@laptop.org</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><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>
<br></div></div>_______________________________________________<br>
Sugar-devel mailing list<br>
<a href="mailto:Sugar-devel@lists.sugarlabs.org" target="_blank">Sugar-devel@lists.sugarlabs.org</a><br>
<a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a><br>
<br></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><br>-- <br>Daniel Narvaez<br>
</font></span></div>
</blockquote></div><br></div>