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 <jafo-python-dev at tummy.com> 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 <jafo at tummy.com> > tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/nnorwitz%40gmail.com >
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4