Re: [PATCH] strbuf_read: skip unnecessary strbuf_grow at eof

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 1, 2015, 16:23 UTC
Message-ID: <xmqq382b8kj0.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20150601105901.GE31792@peff.net>

Jeff King <peff@peff.net> writes:

Show 12 quoted lines

> On Sun, May 31, 2015 at 11:16:45AM -0700, Jim Hill wrote:
>
>> Make strbuf_read not try to do read_in_full's job too.  If xread returns
>> less than was requested it can be either eof or an interrupted read.  If
>> read_in_full returns less than was requested, it's eof. Use read_in_full
>> to detect eof and not iterate when eof has been seen.
>
> I think this makes sense. I somehow had to read this over several times
> to understand that the main point is not the cleanup, but rather the
> space savings from not doing an extra strbuf_grow. Perhaps it is because
> the main idea is mentioned only in the subject. Or perhaps I was just
> being dense.

Even after seeing (not "reading", as it was before my first cup of caffeine ;-) this message 30 minutes ago and then reading the patch with a fresh eye, I had the same impression, until I realized there is "too" at the end of the first sentence.

Perhaps

	The loop in strbuf_read() uses xread() repeatedly while
	extending the strbuf until the call returns zero.  If the
	buffer is sufficiently large to begin with, this results in
	xread() returning the remainder of the file to the end
	(returning non-zero), the loop extending the strbuf, and
	then making another call to xread() to have it return zero.

	By using read_in_full(), we can tell when the read reached
	the end of file: when it returns less than was requested,
	it's eof.  This way we can avoid an extra iteration that
	allocates an extra 8kB that is never used.

In any case, the change is very sensible.  Thanks, both.