apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan Zhakov <i...@visualsvn.com>
Subject Re: Why does apr_file_read() with !APR_XTHREAD use mutexes on Windows
Date Sat, 05 Jun 2010 09:57:39 GMT
On Tue, Apr 20, 2010 at 13:07, Bert Huijben <bert@qqmail.nl> wrote:
>> -----Original Message-----
>> From: Bert Huijben [mailto:bert@qqmail.nl]
>> Sent: vrijdag 16 april 2010 17:28
>> To: dev@apr.apache.org
>> Subject: Why does apr_file_read() with !APR_XTHREAD on Windows
>>
>>       Hi,
>>
>> While profiling subversions file usage performance on Windows, one major
>> slowdown shows:
>>
>> When a file is opened with APR_BUFFERED on Windows all read and file
>> operations are slowed down by a mutex (or actually a critical section),
> even
>> though the function is not documented to be thread safe unless you use
>> APR_XTHREAD.
>>
>> I'm trying to find out why this is implemented this way on Windows, but
> not
>> on the other platforms.
>>
>> * Are all file operations supposed to be slow but thread safe on Windows?
>> * Or is this just to cover up old compatibility issues in other systems.
>> (httpd defaults to threading on Windows)
>> * Can we change this without breaking backwards compatibility?
>> (I'm willing to write patches, etc.)
>> * Or is it a better route to add a new flag that disables this mutex
> around
>> the buffering.
>>
>> Looking at the subversion history of this mutex, I found that it was
>> introduced in r60083 (may 2000) and the documentation on why the mutex
>> was
>> added is nonexisting.
>>
>> Going forward ten years since that revision, we got hyperthreading and
>> multicore systems and the critical section which used to be fast
>> (implemented as an interlocked exchange) is now much slower because it
>> has
>> to perform actual CPU and caching synchronization.
>>
>>
>> I would like to remove this performance penalty of using the mutexes for
>> Subversion (which explicitly documents that you can't use its instance
>> objects in multiple threads at the same time)... What are the recommended
>> steps I should take?
>
> Ping. No response at all in this thread.
>
> Any suggestions on what steps to take to reduce the slowdown?
>
Any updates? I've prepared patch (see attachment) and made some
performance testing. Reading file byte-by-byte many times gives the
following rough numbers:

single core CPU
============
unpatched:   205  (time ticks)
patched:       72    (time ticks)
Performance improvement: 64%

2 core CPU
=========
unpatched:   217  (time ticks)
patched :      92    (time ticks)

Performance improvement: 57%

Any chance to get this committed to trunk and backport to 1.3.x?

-- 
Ivan Zhakov
VisualSVN Team

Mime
View raw message