Re: Unique string storage

Jim Roskind (jar@infoseek.com)
Wed, 6 Apr 1994 10:48:47 +0800

> Date: Wed, 6 Apr 94 10:04:32 MDT
> From: lutz@KaPRE.COM (Mark Lutz)
> Cc: python-list@cwi.nl, amrit@xvt.com, lutz@KaPRE.COM
>
> > [tim writes, after noting that strcmp is typically inline expanded]
> >
> > 2) Profiling is a useless approach for guessing how much time is spent on
> > "attribute access", cuz the code is spread out all over, and parts of
> > it involve the hashing and dict-lookup code that are used for many
> > purposes besides attribute access.
>
> Good point; timings from a set of typical programs would be better.
>

Sorry, but I don't agree. You just have to be clever when you do the
profiling. In this case, it is critical to realize that the standard
inline expansion of strcmp() would destroy visibility of strcmp in a
profile report. It is (IHMO) a simple matter to recompile Python with
a macro redefinition of fstrcmp() for strcmp(). Note that fstrcmp()
is guaranteed (at least for an ANSI C compiler) to induce a function
call, and hence be "profilable." You can then get quite a bit of
visibility into how much time is taken by strcmp(). Again, I assert
that the burden of proof for the usefulness of an optimization lies
with the proponent.

A few year back the question was: "Where's the beef?" Today my
question is: "Where's the [profile] Data?" 8-)

Jim

Jim Roskind
408-982-4469
jar@infoseek.com