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

Re: svn commit: r1712223 - /subversion/trunk/subversion/mod_dav_svn/util.c

From: Ivan Zhakov <ivan_at_visualsvn.com>
Date: Tue, 3 Nov 2015 11:45:24 +0300

On 3 November 2015 at 11:31, Branko Čibej <brane_at_apache.org> wrote:
> On 03.11.2015 09:12, ivan_at_apache.org wrote:
>> Author: ivan
>> Date: Tue Nov 3 08:12:36 2015
>> New Revision: 1712223
>>
>> URL: http://svn.apache.org/viewvc?rev=1712223&view=rev
>> Log:
>> Do not insert newlines in base64 encoded responses in mod_dav_svn. This is
>> slightly reduce CPU usage on the client since it could decode responses with
>> bigger chunks instead line-by-line.
>
> This looks like one of those micro-optimisations that you like to
> complain about ... does it really make a measurable difference?
It's not micro-optimization actually.

> A sane Base64 decoder should just ignore any newlines in the encoded stream and
> not try to split it into lines first. If our decoder /does/ read the
> response line-by-line, then I propose that's a better place for a
> performance improving fix.
>
The problem that XML parser feeds us CDATA in line-by-line basis:
expat parser removes newlines on his own when parses CDATA. One base64
line contains about 60 bytes of data, so we end up processing data
through all stack by such small chunks.

> The (minor) downside of your change is that it makes it just a bit
> harder to read wire dumps.
>
We already encode XML tags without newlines in many places. In some
places we use mod_dav's DEBUG_CR to find whether to add newlines for
easier reading wire dumps.

-- 
Ivan Zhakov
Received on 2015-11-03 09:45:58 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.