httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mladen Turk" <mt...@mappingsoft.com>
Subject RE: [PATCH] apr_table WAS: What to do about tables?
Date Mon, 12 Nov 2001 18:27:24 GMT

-----Original Message-----
> From: Brian Pane [mailto:Brian.Pane@cnet.com]
> Sent: Monday, November 12, 2001 7:03 PM
> To: 'dev@httpd.apache.org'
> Subject: RE: [PATCH] apr_table WAS: What to do about tables?
> 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.

Don't...

> 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.

By the way did someone ever measured the average table size in Apache?
I found that the size is around 25 elements. If I'm not wrong then the brute
force will beet any indexing or whatever method.

I'm sending you the CRC that I'm using for a long time (from snippets).

MT.

Mime
View raw message