[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091025233016.6860d9c7@nehalam>
Date: Sun, 25 Oct 2009 23:30:16 -0700
From: Stephen Hemminger <shemminger@...tta.com>
To: Eric Dumazet <eric.dumazet@...il.com>
Cc: Octavian Purdila <opurdila@...acom.com>, netdev@...r.kernel.org
Subject: Re: [PATCH next-next-2.6] netdev: better dev_name_hash
I overkilled this with more functions and compared filenames as well.
genarated names (dummyNNNN)
Algorithm Time (us) Ratio Max StdDev
kr_hash 277925 152408.6 468448 543.19
string_hash31 329356 5859.4 16042 44.18
SuperFastHash 324570 4885.9 10502 2.29
djb2 327908 5608.5 15210 38.08
string_hash17 326769 4883.6 9896 0.76
full_name_hash 343196 63921.0 140628 343.62
jhash_string 463801 4883.8 10085 1.02
sdbm 398587 9801.7 29634 99.18
filesystem names
Algorithm Time (us) Ratio Max StdDev
kr_hash 278840 152314.9 468717 543.01
string_hash31 331206 5802.1 16004 42.87
SuperFastHash 325938 4887.5 13528 2.88
djb2 330621 5607.1 15333 38.05
string_hash17 331181 4884.9 13274 1.78
full_name_hash 347312 63972.2 141336 343.77
jhash_string 466799 4885.2 13275 1.92
sdbm 403691 9771.7 29629 98.88
Ratio is the average number of buckets examined when scanning
the whole set of names.
1) Increased hash buckets to 1024 which seems reasonable if we are
going to test that many names.
2) Increased name size to 256 so that longer filenames could be
checked and name blocks were not in same cache line
* SuperFastHash is too big to put inline
View attachment "hashtest.c" of type "text/x-c++src" (6873 bytes)
Powered by blists - more mailing lists