httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bp...@pacbell.net>
Subject Re: [PATCH] apr_table WAS: What to do about tables?
Date Fri, 09 Nov 2001 15:26:56 GMT
Mladen Turk wrote:
[...]

>>Based on my really quick reading of your new version of apr_tables.c,
>>the code looks reasonable.  My main worry is that the overhead of
>>the hash table maintenance, including the function call overhead and
>>the need to reindex every time the table is expanded, may offset the
>>performance benefits of hashing.  Do you have any benchmark data
>>to compare the performance of this implementation with the current
>>apr_table_t?
>>
>
>				old apr_table	my implementation
>(microseconds)
>
>add    10000 keys		   40.057			 80.113
>get    10000 keys       7.220.166	      	 60.084
>
>The keys are in the form KEY0...KEY9999
>
>So I agree that you have almost double time to insert the keys, but
>getting values from table shows 120 times performance gain.
>

Thanks for the data.  Does your "add" number represent apr_table_add
or apr_table_set?  I'll assume it's apr_table_set for the following
estimation.

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.

--Brian

P.S.: You may have tried this one already, but another benchmark case
that I think would be valuable is to set the same key value 10000 times
with apr_table_addn, to simulate the DoS attack that can affect table
implementations that handle the multiple-values-per-key case too slowly.



Mime
View raw message