summaryrefslogtreecommitdiffstats
path: root/lib/libalpm/be_local.c
diff options
context:
space:
mode:
authorDan McGee <dan@archlinux.org>2010-12-14 19:36:02 +0100
committerDan McGee <dan@archlinux.org>2010-12-14 19:36:02 +0100
commit919bb6c9e00820c3930067b5985a246a455bef57 (patch)
treeaff800a6e65184a873c02bcb908196b0022047c5 /lib/libalpm/be_local.c
parentc2a73ba989fffb59c1b8ac7edb265a996dfc184d (diff)
downloadpacman-919bb6c9e00820c3930067b5985a246a455bef57.tar.gz
pacman-919bb6c9e00820c3930067b5985a246a455bef57.tar.xz
Used hashed package name in _alpm_pkg_find
This results in huge gains to a lot of our codepaths since this is the most frequent method of random access to packages in a list. The gains are seen in both profiling and real life. $ pacman -Sii zvbi real: 0.41 sec -> 0.32 sec strcmp: 16,669,760 calls -> 473,942 calls _alpm_pkg_find: 52.73% -> 26.31% of time $ pacman -Su (no upgrades found) real: 0.40 sec -> 0.50 sec strcmp: 19,497,226 calls -> 524,097 calls _alpm_pkg_find: 52.36% -> 26.15% of time There is some minor risk with this patch, but most of it should be avoided by falling back to strcmp() if we encounter a package with a '0' hash value (which we should not via any existing code path). We also do a strcmp once hash values match to ensure against hash collisions. The risk left is that a package name is modified once it was originally set, but the hash value is left alone. That would probably result in a lot of other problems anyway. Signed-off-by: Dan McGee <dan@archlinux.org>
Diffstat (limited to 'lib/libalpm/be_local.c')
0 files changed, 0 insertions, 0 deletions