Stop the git abuse

Jesse Keating jkeating at
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

real	0m0.563s
user	0m0.437s
sys	0m0.118s

half of a second.

Jesse Keating
Fedora -- FreedomĀ² is a feature!

More information about the devel mailing list