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