By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,640 Members | 1,598 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,640 IT Pros & Developers. It's quick & easy.

hotspot profiler experience and accuracy?

P: n/a
I have a parser I need to optimize. It has some disk IO and a lot of
looping over characters.

I used the hotspot profiler to gain insight on optimization options. The
methods show up on on the top of this list seems fairly trivial and does
not look like CPU hogger. Nevertheless I optimized it and have 25%
performance gain according to hotspot's number.

But the numbers look skeptical. Hotspot claim 71.166 CPU seconds but the
actual elapsed time is only 54s. When measuring elapsed time instead of
CPU time the performance gain is only 13% with the profiler running and
down to 10% when not using the profiler.

Is there something I misunderstood in reading the numbers?
Jul 18 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
On Tue, 01 Feb 2005 19:24:20 -0800, aurora wrote:
I have a parser I need to optimize. It has some disk IO and a lot of
looping over characters.

I used the hotspot profiler to gain insight on optimization options. The
methods show up on on the top of this list seems fairly trivial and does
not look like CPU hogger. Nevertheless I optimized it and have 25%
performance gain according to hotspot's number.


I can't answer your other question, but general optimization advice, since
I've been in this situation a couple of times: Generally, you're not
going to win in an interpreted language like Python* looping over all
chars. You should either eliminate those loops if possible, or move the
guts of the looping into regular expressions, which are designed to do
that sort of thing as optimally as possible. (I've never looked at the
internals, but I believe the "compile()" function in the re module isn't
just a way of conveniently sticking a regex into a variable; you are
actually creating a compiled and reasonably optimized (as long as you
don't get crazy) character scanner that you simply Can Not beat in pure
Python.)

As a last-ditch scenario, you could go to a C extension, but regexs should
be good enough, and only beatable in the simplest of cases.

Write good REs (you could ask for help, but you should probably just test
it yourself; the key thing to try for, I think, is to put as much into one
RE as possible and ask the match object which thing matched but I may be
wrong; more experienced comments welcomed), and then run the profiler
again.

In general though, the precise numbers coming out of the profiler are less
important than their relationships; as long as the relationships are
maintained the data is still good.

*: At current technology levels. Yes, someday optimization will make
looping over characters in Python even faster than C, or so the theory
goes. That's not today, or even tomorrow, though.
Jul 18 '05 #2

P: n/a
aurora wrote:
But the numbers look skeptical. Hotspot claim 71.166 CPU seconds but
the actual elapsed time is only 54s. When measuring elapsed time
instead of CPU time the performance gain is only 13% with the profiler
running and down to 10% when not using the profiler.

Is there something I misunderstood in reading the numbers?


Well, I'm confused too. Look at my post from a few months ago:
http://tinyurl.com/6awzj
(note that my code contained a few errors and that you need
to use the fixed code that I posted a few replies later).

Perhaps somebody can explain a bit more about this this time? :-)

At the moment, frankly, hotspot seems rather useless.

--Irmen
Jul 18 '05 #3

P: n/a
Thanks for pointing me to your analysis. Now I know it wasn't me doing
something wrong.

hotspot did lead me to knock down a major performance bottleneck one time.
I found that zipfile.ZipFile() basically read the entire zip file in
instantiation time, even though you may only need one file from it
subsequencely.

In anycase the number of function call seems to make sense and it should
give some insight to the runtime behaviour. The CPU time is just so
misleading.
aurora wrote:
But the numbers look skeptical. Hotspot claim 71.166 CPU seconds but
the actual elapsed time is only 54s. When measuring elapsed time
instead of CPU time the performance gain is only 13% with the profiler
running and down to 10% when not using the profiler.
Is there something I misunderstood in reading the numbers?


Well, I'm confused too. Look at my post from a few months ago:
http://tinyurl.com/6awzj
(note that my code contained a few errors and that you need
to use the fixed code that I posted a few replies later).

Perhaps somebody can explain a bit more about this this time? :-)

At the moment, frankly, hotspot seems rather useless.

--Irmen


Jul 18 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.