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

Re: [PATCH] object: measure time needed for resolving hash collisions

From
Jeff King <peff@peff.net>
Date
Sep 15, 2016, 18:49 UTC
Message-ID
<20160915184906.hocai2ho4mkx6n6s@sigill.intra.peff.net>
In-Reply-To
<CAGZ79kZ-rLVijKj31uYgYrLkSCCOaLKWrr8u=6LXnd=gmma+xQ@mail.gmail.com>
On Thu, Sep 15, 2016 at 09:26:22AM -0700, Stefan Beller wrote:
Show 7 quoted lines
> > It may also be possible to really micro-optimize it on some platforms,
> > because we know the size in advance (I'd kind of expect the compiler to
> > do that, but if we're ending up in glibc memcmp then it sounds like it
> > is not the case).
> 
> That stackoverflow link suggests that glibc already has microoptimisations
> for a variety of platforms.

It's definitely micro-optimized in glibc. What I was trying to say is that if we are hitting the glibc implementation, then we know we are handling the "20" at runtime. Whereas the compiler should know that "20" is a constant, and could in theory skip the memcmp() call entirely in favor of something like an unrolled loop.

-Peff
Previous: Stefan BellerNext: Junio C Hamano
Message 5 of 7 in “object: measure time needed for resolving hash collisions”
  1. object: measure time needed for resolving hash collisionsStefan Beller, Sep 15, 2016
  2. Jeff KingSep 15, 2016
  3. Jeff KingSep 15, 2016
  4. Stefan BellerSep 15, 2016
  5. Jeff KingSep 15, 2016
  6. Junio C HamanoSep 15, 2016
  7. Jeff KingSep 15, 2016

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.