[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

FSFS caching and apr_thread_rwlock_t performance on Windows

From: Ivan Zhakov <ivan_at_visualsvn.com>
Date: Fri, 19 Dec 2014 17:37:13 +0300

Originally FSFS caching implementation was using apr_thread_mutex_t to
serialize access to shared data. In r1346122 [1] implementation was
switched to apr_thread_rw_lock_t to improve performance. This change
was released in Subversion 1.8.0

Unfortunately current apr_thread_rwlock_t implementation is very slow
on Windows. As quick workaround FSFS code was patched to select
apr_thread_mutex_t or apr_thread_rwlock_t() depending of platform on
compile time (r1611380 [2]).

In further investigation Bert found why apr_thread_rwlock_t() so slow
on Windows: implementation uses kernel level mutex object instead of
lightweight critical section (critical sections are also used in
apr_thread_mutex_t in most cases).

The simple patch to switch apr_thread_rwlock_t() implementation to use
critical sections (through apr_thread_mutex_t) was proposed on APR
development mailing list [3], but patch was not commited nor reviewed.

So the current situation is:
1. APR has performance problem on Windows that hurts Subversion 1.8.x and trunk
2. Subversion trunk has workaround for this specific problem at compile time
3. Patch proposed to APR mailing list, without any reaction for three months

From my point of view the proposed patch is straightforward and Bert
stated that it makes apr_thread_rwlock_t 10 to 140 times more
efficient on Windows. So the best option will be to commit Bert's
patch, but I cannot do this since I'm not APR committer :(

Thoughts?

[1] http://svn.apache.org/r1346122
[2] http://svn.apache.org/r1611380
[3] http://mail-archives.apache.org/mod_mbox/apr-dev/201408.mbox/%3C31e101cfae30%248670db00%2493529100%24%40qqmail.nl%3E

-- 
Ivan Zhakov
Received on 2014-12-19 15:38:52 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.