Oprofile, swap

[William Cohen]

John Richard Moser wrote:
> I just got my OX laptop (hopefully some kid gets the other one soon... 
> or not), and noticed it's slow and kind of buggy.  I think I'll get a 
> $25 4GB SD card for a SWAP area...
> 
> I should run oprofile too, and have it write to the SD card.  I 
> understand what an interpreted language like Python does to the CPU but 
> it shouldn't be this bad... it's only going to be like 100 times slower? 
>   An actual interpreter will...
> 
>   - Put pressure on the data cache as its code grows
>   - ... but keep the actual interpreter (code) in cache better
>   - Use a relatively large chunk of data for a look-up table
>   - ... or use some convoluted and hard to maintain code
>   - ... or optimally, a look-up table to start the decoding process, if
>     like a CPU bytecode interpreter (Java, CIL) it has an insn + address
>     mode + data (not QUITE optimal for Python, but maybe since simple
>     addition and call happens)
>   - Wind up doing what can easily become a multi-hundred-cycle decoding
>     process for each executed bytecode insn

It would be interesting to know whether there are hot spots in the interpreter 
and whether the interpreter is the major consumer of processor time. In early 
experiments there were some drawing routine in X that was a hotspot:

http://lists.laptop.org/pipermail/devel/2007-March/004163.html
http://lists.laptop.org/pipermail/devel/2007-March/004165.html

> Python rewrites to bytecode (good, interpreting text is slow!  Multiple 
> parsing!) but a lot of the main function calls in the API should be C, 
> not Python (taking some of the pressure off).  This means Python should 
> be doing a lot of logic in native space, rather than interpreting a lot 
> (unlike Java, which had its whole library written in Java...)
> 
> I suggest taking a look at PyPy for Python, which will dynamic recompile 
> Python to native code and likely give some good performance benefits.  I 
> really can't stand JIT compilation and would prefer something that takes 
> advantage of Mono's own facilities, to centralize the effort in the JIT 
> at least (Mono has nice stuff), but IronPython is Microsoft Permissive 
> License which is not OSI approved.
> 
> As for real solutions, I want to profile things and see where they're 
> hanging.  I may need a Python profiler too, to get a look inside the 
> Python code and see if some functions there are also bad; oprofile will 
> tell me if Python itself is spending an ungodly amount of time in its 
> decoder functions but that's it.
> 

I haven't tried it recently on XO machine, but python has some built in profiling:

http://lists.laptop.org/pipermail/devel/2007-March/004401.html
http://wiki.laptop.org/go/Sugar_Performance

-Will