Stop the git abuse

[Panu Matilainen]

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 -