Re: [jamboost] Profiling output inaccuracy

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-07-22 11:58:36

----- Original Message -----
From: "Vladimir Prus" <ghost_at_[hidden]>
To: <jamboost_at_[hidden]>
Sent: Monday, July 22, 2002 12:50 PM
Subject: Re: [jamboost] Profiling output inaccuracy

> David Abrahams wrote:
> > From: "Vladimir Prus" <ghost_at_[hidden]>
> >
> > > Say you call x which call x which calls x. I'll refer to function
> >
> > instances as
> >
> > > x1, x2 and x3 ;
> > >
> > > Cumulative time for x will include
> > > net time for x3 +
> > > net time for x2 + total time for x3 +
> > > net time for x1 + total time for x2
> > > and this is equal to
> > > net time for x1 + 2 * net time for x2 + 3 * net time for x3.
> > >
> > > You're counting the same time several times!
> >
> > Hmm, no wonder recursive calls appeared to be so expensive!
>
> Well... that's why my previous message used calls to 'hashitem' to
compare
> performance.

Heh, I've spent a lot of time tweaking v1 code based on the existing
profile output to try to speed it up. Of course I haven't been getting
results ;-)

> > It seems like a simple fix is possible - put an entry count on
profile_info
> > and only accumulate cumulative time when it goes to zero.
>
> Yea, guess that will work. Comitted the change -- oh... now the profiling
> information looks much more reasonable -- as expected, class.__init__ is
> responsible for the largest fraction of classes overhead.

I'll have to look at some v1 runs again to see how that looks now.

Thanks,
Dave