Perl slowness

[Shachar Shemesh]

Noam Rathaus wrote:
> The only obvious one is that read() shown under strace, takes a 
> significant more time on the new machine than the old one
You can split the difference between the platforms into three groups:
Time spent in the kernel (0.032 seconds)
Time spent in userspace (7.761 seconds)
Time spent sleeping or otherwise scheduled out (7.287 seconds)

strace -c goes a long way, and works very hard, to show us information 
that is not useful to us. It counts CPU time spent in system calls, not 
actual wall time. What may provide a more useful output in this case is 
-T, which will also count time in which the process was sleeping inside 
a system call (which accounts for about half the slowdown).

The second half of the slowdown, the one done in user space, is more 
difficult to trace without the sources (i.e. - the perl sources). 
valgrind has a module for detecting what causes a slowdown, but I doubt 
Noam wants to start analyzing perl to figure out what the different 
areas actually mean.

Shachar
>
> On Tue, Sep 8, 2009 at 5:43 PM, Shachar Shemesh <shachar at shemesh.biz 
> <mailto:shachar at shemesh.biz>> wrote:
>
>     Noam Meltzer wrote:
>>     the time output does looks like you have higher cpu usage for
>>     some reason, so i agree with Shachar on this.
>>
>>     you can also try to pinpoint the place the cpu is spent.
>>     strace and/or ltrace with the '-f -c' flags can help.
>     I'm not sure about ltrace, but strace will not help. Most of the
>     time is spent in user space, not in the kernel.
>
>     Strace may help if the problem is time spent in another process
>     (i.e. - while the main process is sleeping), but it seems Noam has
>     already tried that one and failed to spot any obvious candidates.
>
>     Shachar
>
>>
>>
>>
>>     On Tue, Sep 8, 2009 at 5:24 PM, Shachar Shemesh
>>     <shachar at shemesh.biz <mailto:shachar at shemesh.biz>> wrote:
>>
>>         Noam Rathaus wrote:
>>>         I know the time difference doesn't look too bad, but take a
>>>         bigger code set:
>>>
>>>         Fast:
>>>         real    0m1.682s
>>>         user    0m1.584s
>>>         sys    0m0.064s
>>>
>>>         Slow:
>>>         real    0m16.730s
>>>         user    0m9.345s
>>>         sys    0m0.096s
>>>
>>         These times spell "CPU intensive". Does your library do
>>         anything special? If you try to import a dummy library, does
>>         this still happen?
>>
>>
>>         Shachar
>>
>>         -- 
>>         Shachar Shemesh
>>         Lingnu Open Source Consulting Ltd.
>>         http://www.lingnu.com
>>             
>>
>>
>
>
>     -- 
>     Shachar Shemesh
>     Lingnu Open Source Consulting Ltd.
>     http://www.lingnu.com
>         
>
>


-- 
Shachar Shemesh
Lingnu Open Source Consulting Ltd.
http://www.lingnu.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20090908/13789b8f/attachment.html>