On 05/23/2012 02:12 AM, Jesse Keating wrote:
On 05/22/2012 12:33 AM, Jan Kratochvil wrote:
True, I agree now. It is just so slow (0m2.693s now, 0m4.222s with
drop_caches=3) I expected it waits for network.
Just out of curiosity, which package is that? I'm seeing a much bigger
difference between dropped caches and the following run (from ~6-7
seconds of uncached down to ~0.5s on the next run)
I bet if you traced it, the majority of time is waiting for rpm to
return queries about the spec file.
Well, here's what I see after drop_caches=3 from 'strace -tt fedpkg
verrel' on kernel.spec which is one of the most complicated specs in
Fedora land:
09:09:06.928011 fedpkg exec
09:09:12.699345 python imports done
09:09:13.510192 rpm exec
09:09:15.345425 rpm exit
09:09:15.385441 fedpkg exit
So by the look of things, 2/3 of the execution time is spent importing
python modules. The rpm execution time is heavily dependent on what the
spec actually does, eg in case of kernel.spec this includes ~50
fork+execs of shell, getconf and two python invocations from executing
shell macros.
From plain rpmspec parsing POV (shell macros aside), at top of
callgrind charts sits the rpm bad performance hallmark pattern of
repeated insert/delete, qsort and bsearch cycles (on macros). Changing
the macros engine to use a hash table instead has been on my todo list
for some time now, just not very high in the priorities as spec parse
isn't exactly the most time-critical thing rpm does.
- Panu -
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
