[Python-Dev] seeing off SET_LINENO
Guido van Rossum
Thu, 01 Aug 2002 12:26:09 -0400
> Well, if there's code there, then the debugger stops. I know it's
> confusing to have intuitive behaviour in this area...
> Anyway, I think I'm done now (as you maybe able to tell from the pile
> of patch notification emails than just landed in your inbox :).
> These issues from my original mail in this thread still haven't be
> 4) The patch installs a descriptor for f_lineno so that there is no
> incompatibility for Python code. The question is what to do with
> the f_lineno field in the C struct? Remove it? That would
> (probably) mean bumping PY_API_VERSION. Leave it in? Then its
> contents would usually be meaningless (keeping it up to date would
> rather defeat the point of this patch).
> 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
> 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? (I guess the only difference that -O makes now is
that asserts aren't compiled. :-)
> 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.
--Guido van Rossum (home page: http://www.python.org/~guido/)