[Patches] [ python-Patches-587993 ] alternative SET_LINENO killer

[noreply@sourceforge.net]

Patches item #587993, was opened at 2002-07-29 11:27
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=587993&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Nobody/Anonymous (nobody)
Summary: alternative SET_LINENO killer

Initial Comment:
This patch is a proof-of-concept of another way to
remove the SET_LINENO patch (as opposed to Vladimir's
ancient one).

Instead of rewriting bytecode (ick!) we poke into the
c_lnotab to see if we've moved onto a different line.

The c_lnotab is not the most transparent of data
structures, it has to be said.

I'm not sure this patch is 100% correct -- but I think
the idea can definitely fly.  There will be some more
overhead to tracing than before, but I hope not too
much.  I haven't tested these aspects.

Comments welcome!

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-07-30 09:58

Message:
Logged In: YES 
user_id=6656

I worked out why some of the code in ceval.c wasn't making
sense to me -- it didn't make sense, period.

I've also fixed a number of silly and not so silly bugs in
my patch.  I'm now 99% certain this idea can fly.  The patch
isn't *finished* but the hard bit is done, IMHO.

There are some other points to make, but I think I'll raise
them on python-dev.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-07-29 20:18

Message:
Logged In: YES 
user_id=31435

Dropping out of "vacation mode" long enough to say "mondo 
cool!" and encourage this.  Guido may not agree, but I also 
encourage you to redefine c_lnotab if it can make life easier 
and quicker here.  That subtle compression scheme has 
been the source of several nasty bugs, both in the core C 
code and in Jeremy's compiler pkg (cut 'n paste bugs 
abound here, because few people understand what's really 
needed, so flawed code gets copied with little thought).

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-07-29 15:34

Message:
Logged In: YES 
user_id=6656

Uhh, the instr_[lu]b variables need to keep their values
around the loop; otherwise we might just as well call
PyCode_Addr2Line each time around.

I have another version of the patch that does that, but I
assumed the overhead of doing so was deemed too high, or
someone else would have done this by now.  It's certainly
easier.

Glad to hear it doesn't affect python -O too much.  I was
doing this away from the internet and forgot to keep a clean
copy of the source around for doing comparisons with...

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-07-29 15:18

Message:
Logged In: YES 
user_id=35752

Moving the "int io, instr_ub = -1, instr_lb = 0;"
declaration and the
"io = INSTR_OFFSET();"| statement below the "if
(tstate-c_tracefunc ...)"
test gives a small speedup on my machine and is a little
neater, IMHO.

I was worried that this would slow down "python -O".  That
doesn't seem to
be the case (at least I can't measure it).  Well done.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=587993&group_id=5470