Thanks Daniel.
I need test more...
Gonzalo
On Mon, Nov 11, 2013 at 7:52 PM, Daniel Drake wrote:
> On Fri, Nov 8, 2013 at 12:44 PM, Gonzalo Odiard
> wrote:
> > One of the arguments of the dynamic bindings was a better startup time
> due
> > to not need initialize all the libraries until is nee
On Fri, Nov 8, 2013 at 12:44 PM, Gonzalo Odiard wrote:
> 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
> be lighter than before. Looks like that is not so true.
You should lo
I need flash the xo again to do the tests.
Gonzalo
On Mon, Nov 11, 2013 at 5:53 AM, Daniel Narvaez wrote:
> 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 kern
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
>
>
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 o
On 11 November 2013 00:02, Gonzalo Odiard 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 i
> 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 spee
Here is all that it does if I "from gi.repository import Gtk" before evince.
open("/usr/lib/girepository-1.0/EvinceView-3.0.typelib", O_RDONLY) = 11
close(11) = 0
close(10) = 0
open("/usr/lib/girepository-1.0/EvinceView-3.0.typelib", O_RD
Right, as you can see it only loads gobject introspection stuff. If you do
the import after any other gi import it shouldn't even do that, because
those modules will have been loaded already. It should basically not touch
the disk at all... Which is why it's totally weird that moving the import
hel
Sure. I opened a python console and called from gi.repository import
EvinceView in it. Then I looked at /proc/$console_pid/smaps. There was no
evince library in it. Then in the console I tried to use call
EvinceView.Page(), back to smaps the evince library was there.
Using strace as you did is als
In my system, using
strace -e trace=open,close,read,write,connect,accept -p pid
in another terminal, when I do:
from gi.repository import EvinceDocument
I see:
open("gi.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("gimodule.so", O_RDONLY) = -1 ENOENT (
Can you explain me how you verified the library was not loaded?
Gonzalo
On Fri, Nov 8, 2013 at 8:16 PM, Daniel Narvaez wrote:
> It's not just theory, I verified importing evince doesn't even cause the
> library to be loaded. I don't have a XO 1 to check what is going on myself,
> unfortunately
It's not just theory, I verified importing evince doesn't even cause the
library to be loaded. I don't have a XO 1 to check what is going on myself,
unfortunately.
My suggestion is to *not* checkin this kind of workaround without any clue
about why the change helps, and especially to *not* suggest
Well, should be good know what is happening, but these are real timings.
I know the theory, and that probably was one of the reasons this was not
done before,
but this was what I found.
Gonzalo
On Fri, Nov 8, 2013 at 6:08 PM, Daniel Narvaez wrote:
> Even more confused now...
>
> The two evince
Even more confused now...
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.
That's the normal case in gobject-introspection, libraries are loaded
lazily, when you try to use one of the functions.
Gtk i
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
Another interesting test would be to import the same library using static
bindings and gi, comparing the time.
Btw for reliable timing you want to drop the kernel memory cache before
each start
http://www.linuxinsight.com/proc_sys_vm_drop_caches.html
On Friday, 8 November 2013, Gonzalo Odiard wro
What do you mean with gstreamer initialisation btw? Just the import? That
would be even more surprising because the shell is importing it too and
hence the shared library should be in memory already.
On Friday, 8 November 2013, Gonzalo Odiard wrote:
> There are many issues in Sugar regarding perf
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 i
There are many issues in Sugar regarding performance,
but one of the more visible to the user is how much time the activities
take to start. This is not so evident in newer hardware,
but is important in XO-1. Is so important than by example, Peru will use
sugar 0.94
instead of a newer because o thi
20 matches
Mail list logo
