[OLPC-devel] pygtk performance issue

[Mitch Bradley]

Marco Pesenti Gritti wrote:
> Mitch Bradley wrote:
>> The processor on OLPC is inherently slower than the processors that 
>> are used in modern laptops.  To get ultra low power you have to 
>> sacrifice something.  It seems unlikely that we would be able to hide 
>> that inherent speed differential by a kernel change.  In the short 
>> term, I don't know of any planned hardware changes that would 
>> substantially increase the performance of file system activity on USB 
>> drives.
>>
>
> Ok, this is the kind of feedback I was looking for. What about the 
> internal flash? Is it going to be substantially faster than USB drives?
I wouldn't count on it being enough faster to make a huge difference in 
the case you are investigating.  I expect that the process is mostly 
CPU-bound.  Somebody correct me if I'm wrong, but the kernel buffer 
cache is probably preventing most of those failed opens from having to 
re-access the USB hardware.

You could test that easily; just create/mount a tmpfs (RAM-resident) 
directory and try your script on it.
> I believe that "work smarter" is a key component of the OLPC plan.  It 
> looks like you have found some "low-hanging fruit" that is ripe for 
> the picking.  Improving pygtk to start up in a less "brute force" way 
> would benefit not only OLPC, but everybody else as well.
>
> Definitely. But it's also important to prioritize the work. The whole 
> point of this mail is to figure out how critical the "opening a bunch 
> of files" issues is going to be on the final hardware/kernel.
The current hardware and kernel is a reasonable model for the speed of 
the final system.  We'll certainly make some improvements to the core 
performance of the low-level system, but it won't be an order of 
magnitude*.  So order of magnitude speedups will have to come from 
avoiding unnecessary work, rather than depending on the system to be so 
fast that waste doesn't matter.

*I am, however, confident that we can make huge improvements in the 
stability.
>
> Thanks,
> Marco
>