Jesús Cea Avión <j...@jcea.es> added the comment:

> - why an empty "dtrace" module?

This is preliminary. I am thinking about dynamic probes, something like 
"logging" module but using dtrace. Still experimenting, not sure is actually 
possible.

Martin V Löwis suggested to use "sys.flags".

Undecided yet.

> - I'm worried that you're adding lots of delicate code inside
> critical core functions. Perhaps most of it can be factored out in
> separate functions living in another (dtrace-specific) C file? I
> don't think we really want to maintain some asm("nop") in the GC
> module, and I'm not even talking about the madness in ceval.c.

ceval.c madness is greatly reduced in the last version. I was not happy with it 
either. I am open to suggestions...

The point of DTrace probes is its very low overhead. If I change macros to 
external function calls, your performance will be suffer.

That said, I am open to suggestions, more understandable code, etc.

> - instead of generating code data (line numbers etc.) up front, why
> not generate and cache it lazily? that way, it would only be
> generated when the probes are really used (IIUC)

This case is special. This data is used by the kernel, when a DTrace script 
does a "jstack()". At this moment you can not CALL anything. You don't even 
have loops or "if".

Example: your program seems hangup, aparently. You can write a single line 
DTrace script to dump the jstack and see what your program is doing, even if it 
stuck in, let say, a function call. At this moment you can't call ANYTHING. So 
I precalculate the line offsets at import time, and use the table here. There 
is little else I can do, in kernel context.

> For higher-level benchmarks, I suggest you take a look at
> http://hg.python.org/benchmarks/

Good suggestions. I will check it.

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to