On 7 October 2015 at 14:08, Bert Huijben <bert_at_qqmail.nl> wrote:
>> -----Original Message-----
>> From: ivan_at_apache.org [mailto:ivan_at_apache.org]
>> Sent: woensdag 7 oktober 2015 09:57
>> To: commits_at_subversion.apache.org
>> Subject: svn commit: r1707196 -
>> /subversion/trunk/subversion/libsvn_subr/stream.c
>>
>> Author: ivan
>> Date: Wed Oct 7 07:57:05 2015
>> New Revision: 1707196
>>
>> URL: http://svn.apache.org/viewvc?rev=1707196&view=rev
>> Log:
>> Slightly optimize svn_stringbuf_from_stream() to avoid allocating twice
>> more memory and unnecessary memcpy() when LEN_HINT is equal to final
>> stringbuf
>> length.
>>
>> * subversion/libsvn_subr/stream.c
>> (svn_stringbuf_from_stream): Always preallocate LEN_HINT +
>> MIN_READ_SIZE
>> bytes to be able perform final read without stringbuf reallocation.
>
> Can you explain why hint + MIN_READ_SIZE instead of something like
> MAX(len_hint+1, MIN_READ_SIZE)
>
> I don't know what MIN_READ_SIZE is from just this patch, but it could easily be
> something like 16 Kbyte, while len_hint could be something like 16 for a file like
> 'format' that was just statted to obtain the actual size
>
> 16 Kbyte + 16 bytes for a 16 bytes file looks a bit large... And allocating 16 + 32
> bytes is far more efficient than allocating that huge chunk at once.
>
MIN_READ_SIZE is 64 bytes and it's locally defined in this function.
We cannot use MAX(len_hint+1, MIN_READ_SIZE) because main loop
reallocates buffer if don't have MIN_READ_SIZE remaining. The current
code assumes that MIN_READ_SIZE is small value and I decided to leave
this code intact. It could be improved of course, but I wanted to make
minimum change first.
--
Ivan Zhakov
Received on 2015-10-07 13:27:29 CEST