git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: fprintf_ln() is slow

From
Junio C Hamano <gitster@pobox.com>
Date
Jun 27, 2019, 21:55 UTC
Message-ID
<xmqqimsqae1r.fsf@gitster-ct.c.googlers.com>
In-Reply-To
<20190627212154.GB20250@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 5 quoted lines
> I'm also not entirely convinced it's worth caring about this problem at
> all (whether the solution is buffering here, or just adding the "\n"
> back to the original strings). It's true that p1451 shows off a
> measurable improvement, but I think it's a silly, pathological case. I'd
> be surprised if anybody ever noticed the difference in the real world.
Yup, exactly my thought.
> The biggest benefit I see to dealing with it is not performance, but
> that it makes our messages more likely to appear atomically in the
> output (if multiple entities are writing to stderr).

I was primarily in favor of getting rid of *printf_ln() functions (there are some 200+ callsites if I counted correctly) as I found it a bit distracting.

Previous: Jeff KingNext: Johannes Schindelin
Message 9 of 13 in “fprintf_ln() is slow”
  1. Jeff KingJun 27, 2019
  2. Jeff KingJun 27, 2019
  3. Duy NguyenJun 27, 2019
  4. Ævar Arnfjörð BjarmasonJun 27, 2019
  5. Duy NguyenJun 27, 2019
  6. Junio C HamanoJun 27, 2019
  7. Jeff KingJun 27, 2019
  8. Jeff KingJun 27, 2019
  9. Junio C HamanoJun 27, 2019
  10. Johannes SchindelinJun 27, 2019
  11. Jeff KingJun 27, 2019
  12. Phillip WoodJun 28, 2019
  13. Jeff KingJun 28, 2019

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.