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.
