Ask Your Question

Revision history [back]

The slower cases are running with the debugger enabled.  Debug overhead is proportional to number of byte codes executed so something like nested Python for loops will incur a lot of overhead while most real code does not because compute-intensive looping is actually done in C code in Python's builtins, standard library, or third party modules.  I think this is why the genExpr and genFunc cases are so bad -- the way they are implemented is churning through a lot of Python byte codes.Sorry for the long delay in responding here.  We did not receive the usual notice of new posts for a while.  I think that's been fixed now.

click to hide/show revision 2
No.2 Revision

The slower cases are running with the debugger enabled.  Debug overhead is proportional to number of byte codes executed so something like nested Python for loops will incur a lot of overhead while most real code does not because compute-intensive looping is actually done in C code in Python's builtins, standard library, or third party modules.  I think this is why the genExpr and genFunc cases are so bad -- the way they are implemented is churning through a lot of Python byte codes.Sorry codes.

Sorry for the long delay in responding here.  We did not receive the usual notice of new posts for a while.  I think that's been fixed now.

The slower cases are running with the debugger enabled.  Debug overhead is proportional to number of byte codes executed so something like nested Python for loops will incur a lot of overhead while most real code does not because compute-intensive looping is actually done in C code in Python's builtins, standard library, or third party modules.  I think this is why the genExpr and genFunc cases are so bad -- the way they are implemented is churning through a lot of Python byte codes.

Sorry for the long delay in responding here.  We did not receive the usual notice of new posts for a while.  I think that's been fixed now.