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: > I have tried again cleaning the kernel memory cache before each start > as you suggested > using http://www.linuxinsight.com/proc_sys_vm_drop_caches.html > > 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 > <dwnarv...@gmail.com<javascript:;>> > wrote: > > On 11 November 2013 00:02, Gonzalo Odiard <gonz...@laptop.org<javascript:;>> > 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. > -- Daniel Narvaez
_______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
