httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <Brian.P...@cnet.com>
Subject RE: [PATCH] apr_table WAS: What to do about tables?
Date Mon, 12 Nov 2001 18:02:43 GMT
Mladen Turk <mturk@mappingsoft.com> wrote:

[...]
> Here is the drop-in replacement for apr_table that uses hash indexes to
> table entries.
> 
> I've tested the code to the current httpd from cvs.
> Well, the performance gain isn't as high as I expected (or my testing
> approach is wrong).
> 
> Using ab the total response is aroud 1% or more faster then original, but
> the connection, processing and waiting have 16 % less values (If I
> calculated that correctly).
> 
> Someone has the idea how to measure those precisely?

It's hard to measure the effectiveness of a change like
this with ab, because the time spent in network writes
overshadows the time spent in the table code.

You can overcome this problem somewhat by using ab to
request a very small file--zero bytes, for example.

If you have a profiler like gprof or Quantify, it should
yield more precise numbers.

By the way, I have an alternate implementation of a
table speedup that I wrote late yesterday.  It caches
a 32-bit checksum for each key in the table and compares
checksums to decide whether it can skip the strcasecmp.
It's still O(n), but the idea is to reduce the constant
multiplier.  (The checksum computation basically just
packs the first four bytes of the string into an int and
does some bit masking to normalize to all-uppercase.
I found that using a more expensive checksum, like strlen,
would slow down table performance overall, so I had to use
a very lightweight algorithm for the checksum.)  Once I
get some profile data, I'll post the code if it turns
out to be faster.

--Brian

Mime
View raw message