On 11/08/2014 10:53 PM, Andrew Savchenko wrote: > On Sat, 08 Nov 2014 15:45:30 -0800 Zac Medico wrote: >> On 11/08/2014 03:33 PM, Patrick Lauer wrote: >>> We can choose for "code that works reasonably fast" - portage hasn't >>> gotten any noticeable work on performance in a while, and people have >>> just piled on more and more features and complexity. >> >> Yes, as one of only 2 people who have worked on the resolver in recent >> history, I agree with your statement. There have been lots of features >> added (including EAPI 5 sub-slot rebuilds), with not much thought to >> performance tuning. It will be interesting to do some profiling and see >> what we can improve. >> >>> There's no reason that it takes a minute to start up, >> >> If it takes a minute then it probably means that >> /var/cache/edb/vdb_metadata.pickle got deleted. In that case, it has to >> reload lots of metadata from /var/db/pkg/*/*/*. > > On old hardware it may take dozens of minutes of CPU time. I have > that *.pickle files, I have sqlite metadata cache, I have 100% CPU > usage. It's not an I/O problem. Just take into account that due to > instruction set, Lx cache, frequency and memory speed difference > old CPU-based system may be 20x times slower than recent one.
It could be useful for us to collect profiling data generated on old hardware. If you'd like to help, you can use python's cProfile module to generate statistics for us to analyze. The statistics can be nicely visualized as a shaded call graph by using gprof2dot and graphviz [1]. [1] http://grasswiki.osgeo.org/wiki/Tools_for_Python_programming#cProfile_profiling_tool -- Thanks, Zac
