[Python-Dev] seeing off SET_LINENO

[Michael Hudson]

On Thu, 1 Aug 2002, Guido van Rossum wrote:

> > I think leaving f_lineno there but useless is the way to go.  If we
> > actually make incompatible changes for other reasons, then it can
> > disappear.
> 
> Agreed.

Good.

> > 8) I haven't measured the performance impact of the changes to code
> >    that is tracing or code that isn't.  There's a possible
> >    optimization mentioned in the patch for traced code.  For not
> >    traced code it MAY be worthwhile putting the tracing support code
> >    in a static function somewhere so there's less code to jump over in
> >    the main loop (for i-caches and such).
> > 
> > Still haven't done this.
> 
> I don't care if it slows down tracing, but I'd like it not to slow
> down regular operation.  Of course, since SET_LINENO is gone, it
> should speed things up dramatically; but how does it do compared to
> previous -O mode?  

Currently compiling up two interpreters for pybench testing...

Here goes.  Everything is relative to 221-base, which is 2.2.1 from Sean's 
RPM.  This is the slowest, so all percentages are negative, and more 
negative is better.  I hope the names are obvious.

221-base             +0.00% (obviously)
221-O-base:          -9.69%
CVS-base:           -15.43%
CVS-O-base:         -23.56%
CVS-hacked:         -23.66%
CVS-O-hacked:       -23.70%

(Nearly 25% speed up since 221?  Boggle.  Some of this may be compilation 
options, I guess)

Anyway, it seems I haven't slowed -O down.  At some point I might try 
moving the trace code out of line and see if that has any effect.  Not 
today.

If you want to look at where the improvements are in more detail, I've put 
the pybench files here:

    http://starship.python.net/crew/mwh/hacks/pybench-files.tar.gz

> (I guess the only difference that -O makes now is that asserts aren't
> compiled. :-)

I think so, yes.

> > 9) This patch stops LLTRACE telling you when execution moves onto a
> >    different line.  This could be restored, but
> > 
> >    a) I expect I'm the only persion to have used LLTRACE recently
> >       (debugging this patch).
> >    b) This will cause obfuscation, so I'd prefer to do it last.
> > 
> > No change here either.
> 
> I'm not too attached to LLTRACE.  As long as it's usable for debugging
> massive changes to the VM implementation I'm okay with it.

Good.  I don't suppose you'd actually LLTRACE something without dis output 
in front of you anyway, so this isn't much of a loss. Something I just 
remembered: I turned off LLTRACE for trace functions.  I guess this isn't 
really worth caring about either.

Cheers,
M.