Re: [PATCH] strbuf_write: omit system call when length is zero

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Stefan Beller <sbeller@xxxxxxxxxx> writes:

> In case the length of the buffer is zero, we do not need to call the
> fwrite system call as a performance improvement.
>
> Signed-off-by: Stefan Beller <sbeller@xxxxxxxxxx>
> ---
>
>  This applies on top of v17 for origin/sb/submodule-parallel-update.
>  
>  In case there are other reasons for origin/sb/submodule-parallel-update
>  to need a reroll I'll squash it in. But as this is a pure performance
>  optimization in a case we are not running into with that series and that
>  series is clashing with Davids refs backend series, I figure we may not
>  want to have a reroll for this fix alone.

Yeah, I tend to agree that this change by itself is probably not
worth much.

While I agree with the idea of passing the output from children thru
with as little modification as possible, I think that goal does not
have to be incompatible with the idea you and Jonathan had to ensure
that the output is safe in the presence of incomplete last line.

I think the output made from pp_collect_finished() for "other
finished processes" is known to have the very last part from
finished child, so it would be easy to make sure by calling
strbuf_complete_line() that pp->children[i].err is terminated.

I haven't thought it through how the output from CP_WORKING process
in pp_output() should be kept track of, though.

It might be just a matter of adding a bit "incomplete_last_line" to
the parallel_process.children struct and maintain it every time
pp_output() writes something out (we cannot add an extra newline in
pp_output() because we don't know if the process will have further
output, but we can keep track of the fact that the last output did
not have the final newline).  In pp_collect_finished(), we can use
the bit and the contents of pp->children[i].err to decide if we need
to call strbuf_complete_line() if we did so.

Or something like that ;-)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]