You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Sander Striker <st...@apache.org> on 2003/08/23 22:36:04 UTC
Issue #1429 et al, WAS: RE: Paul, info for releasing 0.28
> From: kfogel@collab.net [mailto:kfogel@collab.net]
> Sent: Friday, August 22, 2003 8:44 PM
> Hi, Paul, welcome back. As you know, there's one issue left in 0.28:
> issue #1429 ("slow checkouts"). Sander Striker's been working on it,
> and has learned that it's not a matter of one single factor that we
> can just *zap* to get faster checkouts. It's about making several
> improvements.
Indeed it is. libsvn_wc and libsvn_ra_dav are on the list. For the
rest it is about overall little inefficiencies accumulating.
> He's going to file a separate new issue for each improvement, and then
> use Saturday to work on one of them (probably some libsvn_wc
> efficiency improvements).
My profile* just showed some data that made me freak, since it tells
me it has a function, apr_allocator_set_mutex, that's being called
about a half a million times, but there is no reference in the source
anywhere(!). It appears that it happens when I let gprof attribute
costs to the exported api alone (the -a switch).
I'm going to call it a night, sleep on it and give it another go in
the morning.
RE: Issue #1429 et al, WAS: RE: Paul, info for releasing 0.28
Posted by Sander Striker <st...@apache.org>.
> From: Tobias Ringstrom [mailto:tobias@ringstrom.mine.nu]
> Sent: Sunday, August 24, 2003 10:21 PM
> Sander Striker wrote:
> > Another thing is the md5 checksums. We might want to think about a
> > little less CPU intensive algorithm, since this one is up there aswell.
> > MD5Transform (which is internal to apr, called by apr_md5_update) is taking
> > ~15% of total checkout time over ra_local. It's at the very top of the
> > flat profile.
>
> This data surprised me, so I did some testing that might be of interest.
> I added code to apr-util to count the number of bytes summed, and for
> your test case, which contains around 290 MiB data, I found that 1181
> MiB was summed (using svn from trunk). I am not familiar with the use of
> checksums in subversion, but it might be possible to reduce the amount
> of summing.
>
> Openssl has a nice speed test for its algorithms, and for MD5 I get the
> following (using "openssl speed md5"):
>
> > The 'numbers' are in 1000s of bytes per second processed.
> > 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
> > 13938.39k 48742.55k 142615.89k 277656.06k 379101.18k
>
> In other words, it sums hundreds of megabytes per second. This openssl
> (from RedHat Linux 9) was compiled with -DMD5_ASM, and I'm running it on
> an Athlon XP 2700+ with Linux 2.6.0-test4.
Ah, good point! apr-util uses a reference implementation. Which means
it's dog slow compared to openssl. We need to teach apr-util to use the
openssl code if it's available.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Issue #1429 et al, WAS: RE: Paul, info for releasing 0.28
Posted by Tobias Ringström <to...@ringstrom.mine.nu>.
Sander Striker wrote:
> Another thing is the md5 checksums. We might want to think about a
> little less CPU intensive algorithm, since this one is up there aswell.
> MD5Transform (which is internal to apr, called by apr_md5_update) is taking
> ~15% of total checkout time over ra_local. It's at the very top of the
> flat profile.
This data surprised me, so I did some testing that might be of interest.
I added code to apr-util to count the number of bytes summed, and for
your test case, which contains around 290 MiB data, I found that 1181
MiB was summed (using svn from trunk). I am not familiar with the use of
checksums in subversion, but it might be possible to reduce the amount
of summing.
Openssl has a nice speed test for its algorithms, and for MD5 I get the
following (using "openssl speed md5"):
> The 'numbers' are in 1000s of bytes per second processed.
> 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
> 13938.39k 48742.55k 142615.89k 277656.06k 379101.18k
In other words, it sums hundreds of megabytes per second. This openssl
(from RedHat Linux 9) was compiled with -DMD5_ASM, and I'm running it on
an Athlon XP 2700+ with Linux 2.6.0-test4.
/Tobias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org