Hi, Yesterday i started to analyze pacman's internal. pacman's db speed is typically bound by your systems IO performance: It has to read all db files, if you search repositories. But i was also surprised by the CPU time utilized. So i started profiling "pacman -Ss test": calls ms/call ms/call name 3751 0.01 0.01 _alpm_list_add_sorted 2088191 0.00 0.00 _alpm_pkg_cmp _alpm_list_add_sorted is called 2088191 times while building the pkgcache. This is because every package is sorted into a linked list while scanning the database files: while((info = _alpm_db_scan(db, NULL, infolevel)) != NULL) { ... db->pkgcache = _alpm_list_add_sorted(db->pkgcache, info, _alpm_pkg_cmp); ... Because on each insert the list has to be traversed, pkgcache building has time complexity of O(n^2). Merge-sort is the quickest sort algorithm for linked lists (O(n*log(n)). So i changed above code to use merge-sort. Results on my System: bash-3.2$ time ./src/pacman/pacman.static.old -Ss test >/dev/null real 0m0.791s user 0m0.432s sys 0m0.228s bash-3.2$ time ./src/pacman/pacman.static -Ss test >/dev/null real 0m0.493s user 0m0.232s sys 0m0.260s bash-3.2$ Well, only 0.2 seconds for 70 lines of code patch ;) The different complexity becomes obvious, if you use large repositories. I created a 15000-dummy-packages repository: bash-3.2$ time ./src/pacman/pacman.static.old -Ss test >/dev/null real 0m5.530s user 0m4.588s sys 0m0.828s bash-3.2$ time ./src/pacman/pacman.static -Ss test >/dev/null real 0m2.127s user 0m0.836s sys 0m1.032s Don't be surprised by the small real time. I started each command multiple to prevent IO. Jürgen