httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruediger Pluem <rpl...@apache.org>
Subject Re: AW: [PATCH] mod_disk_cache: store/read array & table
Date Tue, 24 Jan 2006 21:15:29 GMT


On 01/24/2006 06:27 PM, Brian Akins wrote:
> Plüm wrote:
> 
>> To be honest I do not understand why Brian creates its own buffered
>> input / output reading. I think that header files are rarely larger
>> than 4K.
>> And the current code already buffers 4K when APR_BUFFERED is set as a
>> flag for
>> apr_file_open (which is set).
> 
> 
> 
> in current mod_disk_cache:
> 
> -copy from OS buffer (OS may copy from disk) into apr_file_t buffer
> -copy from apr_file_t buffer to user's buffer (apr_file_gets etc.)
> -use apr_table_set and add or apr_pstrdup(this makes a copy of the string).
> 
> So 3 copies of same data and several allocations (apr_pcalloc, etc)
> 
> 
> In my meta_file:
> -copy from OS buffer (OS may copy from disk) into meta_file_t buffer
> -use apr_table_setn and addn
> 
> only 1 copy and 1 apr_pcalloc (or equivalent)

That sounds good, but thats more about the parts I haven't checked so far.
Sorry for nit picking on this, but you said that your patch will save disk
reads and syscalls and I still do not see this.
I see that we save cycles (which is also good) by avoiding to copy data
around. Maybe the allocations that are used in the current process cause
additional brk syscalls and malloc calls to the clib, but as we are using
the pools I am not quite sure if this is significant.
As said, for the cycle saving aspect I need time to check for further comments.


Regards

Rüdiger


Mime
View raw message