Is Browse a lot slower to start on 0.100 vs 0.94 even if you drop the caches on both? On Monday, 11 November 2013, Gonzalo Odiard wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I have tried again cleaning the kernel memory cache before each start as you suggested using <a href="http://www.linuxinsight.com/proc_sys_vm_drop_caches.html" target="_blank">http://www.linuxinsight.com/proc_sys_vm_drop_caches.html</a> echo 3 > /proc/sys/vm/drop_caches sync The time advantage in Browse disappear :( In the Write activity not, but have more sense, because is not only importing but is using the library to locate the text to speech plugin, then is doing something. Maybe is time to add the tts functionality in the toolkit, too much code copied in the activities. Gonzalo On Sun, Nov 10, 2013 at 8:10 PM, Daniel Narvaez <<a href="javascript:;" onclick="_e(event, 'cvml', 'dwnarvaez@gmail.com')">dwnarvaez@gmail.com</a>> wrote: > On 11 November 2013 00:02, Gonzalo Odiard <<a href="javascript:;" onclick="_e(event, 'cvml', 'gonzalo@laptop.org')">gonzalo@laptop.org</a>> wrote: >> >> >> >>> Local imports are a really bad idea for code maintenance. >>> >> >> I know, and we have discouraged that in the past. >> >> That is the reason I said "I think this work of identify big libraries >> used only in specific moments, >> can be applied in other cases." >> >> In the case of gstreamer, used to do text to speech, almost the same code >> is copied >> in a few activities (Speak, Clock, Memorize, Write, at least) >> The code check if the espeak plugin in gstreamer is available, and if not >> try use espeak >> in the command line. Then need initialize gstreamer, and look for the >> plugin. >> That take a few seconds, and is not needed do it before the activity >> starts. > > > I'm not sure to understand this, I should probably see the code. > > But all that I'm saying is that gi.repository imports are supposed to have > virtually no performance impact, as we have also verified stracing. Big or > small library doesn't matter. > > If they do have a performance impact we need to understand why, before > trying to work around the problem by moving imports around. </blockquote> -- Daniel Narvaez