Boy, too little sleep and too much coding is blurring my mind. You
are correct, strcmp() is not typically inlined, and fstrcmp() is a
pigment :) of my imagination. Somehow I misread ... and thought this
was the problem obscuring finding how much strcmp() time was spent.
Sorry to have injected this confusion.
> > [jim]
> > [explaining that strcmp can be accounted for by renaming
> > it, even if it is inlined]
>
> Sure, but the piece you quoted above wasn't talking about strcmp! strcmp
> is of varying importance to the various attribute-access techniques
> Python uses, and Python uses strcmp for things other than attribute
> access too. So finding out where strcmp fits in a profile doesn't tell
> us how much time is spent on attribute access: the latter comprises much
> more than strcmp time, and not all strcmp time counts as attribute access
> time. Pieces of attribute access are done in _many_ places in the code,
> and the routines called from those places are also called for other
> reasons.
I expect that the use of strcmp() represents a very easy to obtain
upper bound on the (execution speed) performance gains that could be
achieved via unique-ification. In truth, as you point out, there are
probably going to be plenty of other uses of strcmp() that would not
be removed by unique-ification. In addition, even with
unique-ification, there will be a fair amount of strcmp() activity.
It just surprises me that so much discussion and conjecture proceeding
with no basis in fact. If strcmp does not dominate, then the
discussion is pretty much history. If it does, then as Tim pointed
out some closer scrutiny seems worth while. If the facts are there,
let the speedup thought begin. (I wish I could say that in latin, it
would probably sound very cool!).
> Placing strcmp would only settle the bet Don & I have going about strcmp
> itself <avaricious grin>. I'll grant that if strcmp is a heavy hitter in
> a "typical program" that isn't crunching many user-defined string
> objects, then Don's probably right (i.e., both that strcmp accounts for
> lots of Python's runtime, & that this is so specifically because of its
> current role in attribute access).
I've expressed my personal rule about profiling many times: Every time
I *guess* where all the time is spent, I'm wrong. After I've seen the
profile data, it is "obvious" where the time is spent. In the case of
Python, I'm soon going to be motivated enough to just get the *real*
answer myself, but for now, I'd note that it is not (to me) dead
obvious that all the attribute lookup causes Python to strcmp() itself
to death. I'd guess that there is a fair amount of pointer following,
a bunch of switching, lots and lots of little function calls, etc. In
general, I'd hope that most of the compare activity is done by a hash
table, and then a quick strcmp() would end the ordeal. When an
attribute is looked up in several scopes before finding a match, it
wouldn't surprise me to hear that it had no hash matches up until that
point, and hence no strcmp() activity. I would really expect (...I
know, I said I'd be wrong :-) ) the allocation and storage of data to
be the ultimate killer (it has been in most OO systems I've played
with). I've seen a lot of hints that Guido has optimized a lot of the
alloc areas, so I expect he's more than in tune with where the time is
being spent (i.e., too bad he's on vacation just now).
When it comes to surprising results from a profiler, who (other than
Tim) would have believed the performance benefit of using the global
keyword in Python? I tell you, the profiler always knows best.
Jim
Jim Roskind
408-982-4469
jar@infoseek.com