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

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

From
Duy Nguyen <pclouds@gmail.com>
Date
Sep 26, 2013, 11:14 UTC
Message-ID
<CACsJy8C_Rr=2tsi_8TmGnHy85qBND1tNby7Nou4O4eqFTOBzgg@mail.gmail.com>
In-Reply-To
<20130926110818.GE6615@paksenarrion.iveqy.com>
On Thu, Sep 26, 2013 at 6:08 PM, Fredrik Gustafsson <iveqy@iveqy.com> wrote:
Show 71 quoted lines
> On Thu, Sep 26, 2013 at 05:26:27PM +0700, Duy Nguyen wrote:
>> 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
OK I have to say I don't see any justification for more code then.
-- 
Duy
Previous: Fredrik GustafssonNext: Karsten Blees
Message 23 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.