On Monday 29 March 2010 16:32:08 you wrote:
> [CC to dev_at_apr.apache.org]
> From: Stefan Fuhrmann [mailto:stefanfuhrmann_at_alice-dsl.de]
> > Under Windows, a significant part of the overall runtime
> > is spent in writing data to the (already buffered) APR
> > file implementation. It seems that the mutex serializing
> > the buffer access in apr_file_write is expensive.
> > Also, >50% of all write requests are 2 bytes or smaller
> > (i.e. line endings and empty lines). For them, the deep
> > call hierarchy constitutes a large overhead on register-
> > lacking x86.
> > This patch eliminates far over 90% of all write requests
> > bringing the portion of time spent in _svn_io_file_write_full
> > down from about 7 to below 3 percent on 32 bit Windows.
> > Performance gain is ~1% under Linux but due to the
> > larger async I/O and mutex overhead it is about 4%
> > under Windows:
> Hi Stefan,
> Thanks for looking into this.
> I'm just wondering why APR does use the mutexes even though APR_XTHREAD
> isn't passed?
> Maybe because the mutex APR uses, a critical section, is more costly now
> than when this code was implemented several years ago?
> (On a singlecore machine a simple interlocked increment is very cheap, but
> on a multicore machine it requires at least some synchronization).
> Looking at the APR help it might be better to fix the buffering in APR,
> than to add yet another level of buffering. (Our buffer, APR's buffering
> and then the OS buffering).
> After a quick search through the apr code it seems that only windows tries
> to make file writes always thread safe, while other operating systems use
> APR_XTHREAD as a trigger.
> The Windows code also enables overlapped IO on APR_XTHREAD, so there could
> be some valid use where you want thread safe code, but not overlapped. But
> why only do this on Windows? (Maybe the APR team can answer this question).
Thank you for the feedback. I will try to come up with a patch
that reduces the APR file access overhead. Depending on
the results, I would then either send a patch to the APR team
or continue the discussion here.
Received on 2010-03-30 18:17:19 CEST