This is probably orthogonal to the problem, however, you may want to look into trying to speed up Python/errors.c. This link will probably not work due to sessions, but click on the latest run for python and Python/errors.c
http://coverage.livinglogic.de/coverage/web/selectEntry.do?template=2850&entryToSelect=547460 If you look at the coverage numbers, many functions are called millions of times. In many cases traceback is passed as NULL in other functions within errors.c. If you could get rid of that check and possibly others and do some fast pathing in there, it might speed up exceptions some (or normal cases where exceptions are raised internally, then discarded). n -- On 5/24/06, Sean Reifschneider <[EMAIL PROTECTED]> wrote: > We've done some more research on it, and Richard Jones is working on it > right now. We'll see how it works, probably tomorrow. > > Thanks, > Sean > -- > If you don't have time to do it right, when will you ever find time to do > it over? > Sean Reifschneider, Member of Technical Staff <[EMAIL PROTECTED]> > tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/nnorwitz%40gmail.com > _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
