> -----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 |
- Unnamed multipart/mixed (inline, None, 0 bytes)
|