Perl slowness

Perl slowness

Noam Rathaus noamr at beyondsecurity.com
Tue Sep 8 18:49:13 IDT 2009


Thanks Dotan for the insight

2009/9/8 Dotan Shavit <dotan at shavitos.com>

> On Tuesday 08 September 2009, Noam Rathaus wrote:
> > So I am stuck
> >
> > Grrr
> >
> > Anyone with ideas on how I can understand why "my packages" are causing
> > issues, while apparently, "perl-provided" packages such as LWP::UserAgent
> > dont?
> http://www.gksoft.com/a/fun/catch-lion.html
>
> >
> > On Tue, Sep 8, 2009 at 5:58 PM, Shachar Shemesh <shachar at shemesh.biz>
> wrote:
> > >  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>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>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/a9905540/attachment.html>


More information about the Linux-il mailing list