Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!news.glorb.com!news-out.readnews.com!transit3.readnews.com!panix!gordon From: John Gordon Newsgroups: comp.lang.python Subject: Re: log and figure out what bits are slow and optimize them. Date: Fri, 10 Feb 2012 23:06:52 +0000 (UTC) Organization: PANIX Public Access Internet and UNIX, NYC Lines: 28 Message-ID: References: NNTP-Posting-Host: panix2.panix.com X-Trace: reader1.panix.com 1328915212 19963 166.84.1.2 (10 Feb 2012 23:06:52 GMT) X-Complaints-To: abuse@panix.com NNTP-Posting-Date: Fri, 10 Feb 2012 23:06:52 +0000 (UTC) User-Agent: nn/6.7.3 Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:20203 In Kev Dwyer writes: > *Any* instrumentation code is going to affect performance. Funny story about that... I wanted to profile some code of mine, and a colleague recommended the 'hotshot' module. It's pretty easy to use: there are functions to start profiling, stop profiling and print results. So I added the function calls and ran my code.... and it took a really long time. I mean a REALLY long time. In fact I eventually had to kill the process. I briefly wondered if my coworker was playing a prank on me... then I realized that I had neglected to call the function to stop profiling! So when I went to print the results, it was still profiling... endlessly. (Okay, maybe it wasn't that funny.) -- John Gordon A is for Amy, who fell down the stairs gordon@panix.com B is for Basil, assaulted by bears -- Edward Gorey, "The Gashlycrumb Tinies"