On Sun, 2005-11-06 at 23:00 -0500, Greg Hudson wrote:
> On Sun, 2005-11-06 at 22:15 -0500, Daniel Berlin wrote:
> > 2. svn_stream_readline to read the hash tables for directories and
> > revprops, again and again and again and again (still, because every
> > svnserve instance it). On gcc.gnu.org, this is actually cpu bound, but
> > still wastes about >20% of the cpu time per session, which is quite
> > high. When it *does* hit the disk, it's ridiculously slow, because it
> > uses a 1 byte buffer.
>
> The 1 byte buffer issue is a one-line fix, if you can figure out where
> the file is opened and add APR_BUFFERED.
Will do.
> > For 1.4, I think we need to do something about the serialized
> > hashtables. Trivially, you could just prepend an encoded integer to
> > each line instead of using something that goes searching for newline.
>
> I'm a little confused. If I remember right, the format of a serialized
> hash table is a succession of:
>
> K <n>\n<n bytes of data>\n
> V <m>\n<m bytes of data>\n
>
> I might have picked a slightly different format, but I don't see how you
> can improve the intrinsic efficiency much.
Not intrinsicly, but without cross-file inlining, you get screwed here
by the call overhead to svn_stream read. if you read them a ton of
times.
> Punt the readline calls and
> read character-by-character, and you should get the same efficiency as
> you'd get with those prepended integers.
Possibly.
Anyway, i see there is actually some room for avoiding readline touching
a few bytes here.
We can make it avoid 3 more bytes than it does now to read the "V
<number>" and "K <number>" lines. i'll see if it makes any real
difference.
BTW, another issue is that most of our revision files, when compressed
with SVNDIFF1, consist of large plaintext hashtables and lines of
changes :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 7 05:40:48 2005