| 1 |
On Mon, Jan 13, 2014 at 5:49 PM, Alec Warner <antarus@g.o> wrote: |
| 2 |
[...] |
| 3 |
> |
| 4 |
> This is not meant to imply that portage is always fast; there are plenty of |
| 5 |
> other modules (such as the aforementioned backtracking) that can take a long |
| 6 |
> time to find solutions. That is partially why you see Tomwij turning off |
| 7 |
> that feature. It is helpful for users cause it can automatically find |
| 8 |
> solutions for users that are otherwise unsolvable (and thus avoids the user |
| 9 |
> having to find a solution to the depgraph manually.) |
| 10 |
|
| 11 |
Yeah, correct. But it would be nice if Portage backtrack_depgraph() |
| 12 |
would memoize (asynchronously serializing to disk, for instance) |
| 13 |
partial results for later use. |
| 14 |
AFAIR, last time I checked, it wasn't doing that. |
| 15 |
|
| 16 |
Also, it would be nice if the aux_db cache of the vdb could be stored |
| 17 |
in a sqlite3 db rather than in RAM. This dict is consuming a huge cut |
| 18 |
of memory for little reason (a single vdb.dbapi.match() can eat 100MB |
| 19 |
of RAM). |
| 20 |
We know how Python deals with freed memory... Sigh... |
| 21 |
|
| 22 |
> |
| 23 |
> -A |
| 24 |
> |
| 25 |
>> |
| 26 |
>> |
| 27 |
>> -- |
| 28 |
>> Luis Ressel <aranea@×××××.de> |
| 29 |
>> GPG fpr: F08D 2AF6 655E 25DE 52BC E53D 08F5 7F90 3029 B5BD |
| 30 |
> |
| 31 |
> |
| 32 |
|
| 33 |
|
| 34 |
|
| 35 |
-- |
| 36 |
Fabio Erculiani |
Archives