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

Re: [PATCH v2 0/5] New hash table implementation

From
Fredrik Gustafsson <iveqy@iveqy.com>
Date
Sep 26, 2013, 11:08 UTC
Message-ID
<20130926110818.GE6615@paksenarrion.iveqy.com>
In-Reply-To
<CACsJy8BQDwHJiDyaOfcmOSg+=jpj-NyCTtw1vLwppSwYxF5hhA@mail.gmail.com>
On Thu, Sep 26, 2013 at 05:26:27PM +0700, Duy Nguyen wrote:
Show 17 quoted lines
> On Thu, Sep 26, 2013 at 5:16 PM, Fredrik Gustafsson <iveqy@iveqy.com> wrote:
> > On Tue, Sep 24, 2013 at 11:50:16AM +0200, Karsten Blees wrote:
> >> Tests can be reproduced with 'time echo "perfhash[map] <method> 1000" | ./test-hashmap', see test-hashmap.c for definition of method flags.
> >
> > So I'm still curious about the actual performance improvements for git.
> > I runned git describe on the linux kernel with both the old hashmap and
> > this new one:
> >
> > ...
> >
> > I can't see any improvements at all here. What do I miss? Am I running
> > git describe in the wrong way? Does linux.git have too few tags to be
> > important?
> 
> I wonder if it makes any difference if there are a lot more refs. I
> hear gerrit creates a lot but don't know how many. linux-2.6 has ~350
> refs. How about increasing the number of refs to 3500 refs?

So I runned: for i in $(git rev-list HEAD ); do git tag "tag$i" $i ; done

in my linux repo and aborted it after a while: iveqy@minilla:/srv/slask/linux$ git tag | wc -l 9323

So it's a few at least. Not sure how those artificial tagnames would hurt or improve the performance.

Old hashtable ============= iveqy@minilla:/srv/slask/linux$ time ../git/git describe HEAD v3.12-rc2-83-g4b97280

real 0m0.384s user 0m0.288s sys 0m0.092s iveqy@minilla:/srv/slask/linux$ time ../git/git describe HEAD v3.12-rc2-83-g4b97280

real 0m0.383s user 0m0.284s sys 0m0.100s iveqy@minilla:/srv/slask/linux$ time ../git/git describe HEAD v3.12-rc2-83-g4b97280

real 0m0.386s user 0m0.312s sys 0m0.072s

New hashtable ============= iveqy@minilla:/srv/slask/linux$ time ../git/git describe HEAD v3.12-rc2-83-g4b97280

real 0m0.382s user 0m0.300s sys 0m0.084s iveqy@minilla:/srv/slask/linux$ time ../git/git describe HEAD v3.12-rc2-83-g4b97280

real 0m0.382s user 0m0.288s sys 0m0.092s iveqy@minilla:/srv/slask/linux$ time ../git/git describe HEAD v3.12-rc2-83-g4b97280

real 0m0.384s user 0m0.296s sys 0m0.088s

-- 
Med vänliga hälsningar
Fredrik Gustafsson

tel: 0733-608274
e-post: iveqy@iveqy.com
Previous: Duy NguyenNext: Duy Nguyen
Message 22 of 24 in “New hash table implementation”
  1. 0/5 New hash table implementationKarsten Blees, Sep 10, 2013
  2. 1/5 add a hashtable implementation that supports O(1) removalKarsten Blees, Sep 10, 2013
  3. Junio C HamanoSep 11, 2013
  4. Karsten BleesSep 23, 2013
  5. Junio C HamanoSep 12, 2013
  6. Karsten BleesSep 23, 2013
  7. 2/5 buitin/describe.c: use new hash map implementationKarsten Blees, Sep 10, 2013
  8. 3/5 diffcore-rename.c: move code around to prepare for the next patchKarsten Blees, Sep 10, 2013
  9. 4/5 diffcore-rename.c: simplify finding exact renamesKarsten Blees, Sep 10, 2013
  10. 5/5 diffcore-rename.c: use new hash map implementationKarsten Blees, Sep 10, 2013
  11. 0/5 New hash table implementationKarsten Blees, Sep 24, 2013
  12. 1/5 add a hashtable implementation that supports O(1) removalKarsten Blees, Sep 24, 2013
  13. 2/5 buitin/describe.c: use new hash map implementationKarsten Blees, Sep 24, 2013
  14. 3/5 diffcore-rename.c: move code around to prepare for the next patchKarsten Blees, Sep 24, 2013
  15. 4/5 diffcore-rename.c: simplify finding exact renamesKarsten Blees, Sep 24, 2013
  16. 5/5 diffcore-rename.c: use new hash map implementationKarsten Blees, Sep 24, 2013
  17. Fredrik GustafssonSep 24, 2013
  18. Tay Ray ChuanSep 24, 2013
  19. Karsten BleesSep 26, 2013
  20. Fredrik GustafssonSep 26, 2013
  21. Duy NguyenSep 26, 2013
  22. Fredrik GustafssonSep 26, 2013
  23. Duy NguyenSep 26, 2013
  24. Karsten BleesSep 26, 2013

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.