Python IS slow ! [was] Re: Python too slow for real world

[Markus Kohler]

Christian Tismer wrote:
> 
> Hi Guys, I think we are missing something
> 
> Markus Kohler wrote:
> >
> > Fredrik Lundh wrote:
> > >
> > > Markus Kohler wrote:
> > > > > GvR:
> > > > > Also, it allocates each stack frame as a separate object.
> > > > > So that's at least two memory allocation/free operations
> > > > > per procedure call.
> ...
> > > iirc, the self people discovered that two optimizations
> > > dominated everything:
> > >
> > > -- method and block in-lining
> ...
> > > -- call-site caching
> 
> This is all wonderful stuff. But I think we are
> missing one point, and if I didn't go completely nuts
> last night, there might be some fairly low hanging
> fruit which could save 30% of runtime, at least speaking of NT.
> 
> After Markus' recommendation, I loaded a trial version of
> Visual Quantify, a tool for timing of compiled code.
> This tool works with optimized code very well, finds
> every system call and so on.
> 
> I configured Quantify to ignore all .dll files but python15.dll
> and msvcrt.dll, to get an idea where the core spends
> most of its time.
> 
> Test 1: Running python.exe with the commandline
> -c "from test.pystone import *;map (lambda x:main(), range(10))"
> 
> Result time: 22.36% malloc, 14.35% free.
> 
> Test 2: Running pythonw.exe and Idle, and removing again
> all system calls and Tcl/Tk calls, just keeping the two dlls as
> above:
> 
> Result time: 19.47% malloc, 12.29% free.
> 
> Which tells me that if we could avoid most of these calls
> and provide a very fast allocation scheme for small blocks,
> I believe a single extension module would gain 25% of win!
> 

I think I have seen that too. But as far as I can remember It didn't 
appear in all my test cases. I would need to check that. 

Markus
-- 
Markus Kohler  mailto:markus_kohler at hp.com