On 7 October 2015 at 14:08, Bert Huijben <b...@qqmail.nl> wrote: >> -----Original Message----- >> From: i...@apache.org [mailto:i...@apache.org] >> Sent: woensdag 7 oktober 2015 09:57 >> To: comm...@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
