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 Sun, 11 Nov 2001 18:41:38 GMT


> -----Original Message-----
> From: Brian Pane [mailto:bpane@pacbell.net]
> Sent: Friday, November 09, 2001 4:27 PM
> To: dev@httpd.apache.org
> Subject: Re: [PATCH] apr_table WAS: What to do about tables?
>
> Here's the distribution of CPU time to these functions in a recent CVS
> snapshot of 2.0:
>
> apr_table_set/apr_table_setn:  3.0% of usr CPU
> apr_table_get:                 2.0%
> apr_table_add:                 0.24%
>
> Based on these numbers, if you double the cost of apr_table_set and
> reduce the cost of apr_table_get by a factor of 120, the httpd overall
> will get *slower*.
>
> If you can improve the performance of updates in your implementation,
> though, then the table-with-index approach would be a big win.

I'm posting the new table indexing schema that doesn't require reindexing on
table_set when duplicate keys found, or when resizing table.

The table implementation is named apr_stable, just to be able to compare
with original. I've focused on add/set/get so these are only implemented for
now.
I'm sending two test programs, one for apr_table, and other for the new one.

Here are the results of benchmarks (useconds)
		old		new
seq add		50.072		60.087
seq set		22.782.760	60.086
seq get		370.533		10.015
rnd add		40.058		40.057
rnd set		28.370.795	3.655.256
rnd get		26.628.289	40.058

But... It would be nice to benchmark those using some real data.

Do I have some +1 to continue working on that?

MT.

Mime
View raw message