On 05/22/2012 11:53 PM, Panu Matilainen wrote:
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.
OOps, I hope my message didn't come across as placing blame or throwing
rpm under the bus. I suspected it was a spec much like the kernel that
does a lot of complicated macro work to figure out things like name,
version, release. Also, I meant it as something I can't do much about
in fedpkg land.
fedpkg does do a fair amount of python imports. I could probably move
some of those around to be more lazy loaded when a property that
requires them gets accessed, but that makes the code harder to manage.
In practical usage on simple rpms, the amount of time I wait for verrel
to return is so small as to not really interrupt my work flow.
$ time fedpkg verrel
pungi-2.11-2.fc18
real 0m0.563s
user 0m0.437s
sys 0m0.118s
half of a second.
--
Jesse Keating
Fedora -- Freedom² is a feature!
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel