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

Re: r1344347 - stream buffering in config_file.c

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Fri, 4 Apr 2014 12:21:42 +0100 (BST)

Bert Huijben wrote:

> Julian Foad wrote:
>>>> URL: http://svn.apache.org/viewvc?rev=1344347&view=rev
>> This commit implements buffering of a generic stream, directly in the config
>> file parser. Would it not be better to implement buffering of a generic stream
>> as a generic module?
>
> Perhaps...
>
> But a patch like that didn't allow speeding up the test suite by 15% in one
> afternoon. This was a very local patch with a very huge result. (And as it
> was very local it is easy to remove it when somebody else optimizes it in a
> different place).

Sure -- I appreciate why it was worth doing that way.

> [...]
>
> And just abstracting it, just for abstracting will add more overhead... (The
> current code is all in one C file and will be completely inlined by every
> compiler... Which is impossible if we need 3 callback and/or shared library
> calls for reading every byte... Even worse when that is taking out mutexes
> such as the apr read code)

I don't think it's fair to assume that an abstraction need be that inefficient, although I admit that an implementation easily can be that inefficient if we don't take care of it.

Part of what I was thinking is, why are we re-inventing the standard <stdio.h> streams interface (fread, fgetc, fungetc, ...) in Subversion? And I started wondering if we could hook in to the standard streams. The GNU C library (glibc) does provide hooks for doing this:

  http://www.gnu.org/software/libc/manual/html_mono/libc.html#Custom-Streams

But it's not standardized, and Windows doesn't seem to provide any such facility.

I don't think we need to do anything right now, but I wanted to note the suggestion.

- Julian
Received on 2014-04-04 13:22:19 CEST

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.