Stop the git abuse
jkeating at redhat.com
Wed May 23 15:30:13 UTC 2012
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
half of a second.
Fedora -- Freedom² is a feature!
More information about the devel