On 03/15/10 03:19 PM, Bart Smaalders wrote:
On 03/12/10 21:12, Shawn Walker wrote:
Greetings,
The following webrev contains fixes for the following issue:
15176 imageplan keeps solver cache and catalog data too long
thanks for doing this....
One minor change you may wish to consider is adding an
argument to self.__cleanup() and returning it....
604 rval = blank_solver.solve_install(existing_freezes, proposed_dict,
new_excludes)
605 self.__cleanup()
606 return rval
becomes
return self.__cleanup(blank_solver.solve_install(existing_freezes,
proposed_dict, new_excludes))
but that's minor...
I'll change it.
What performance implications does this have for a machine w/
sufficient memory and a slow CPU?
I have a re-worked version that I'll send out tomorrow. With that
version, uninstall is the same for a case like "pkg uninstall --no-index
system/manual" and only 8% slower for "pkg install system/manual" on a
T5120 or about 7 seconds. I should note that 7 seconds is relatively
flat, that is, for the current /dev catalog, it wouldn't matter how many
packages you're uninstalling or installing.
So yes, there's a tradeoff here on systems w/ slow single-threaded CPU
performance between saving memory and operation performance.
If I leave the catalog data loaded instead of dumping it after calling
the solve_* functions, my other changes combined will still save some
memory, but not nearly as much.
Ultimately, the biggest savings are going to come from the action
marshalling work that's being investigated. From what I recall, on a
b131 system upgrading to b133, around 300MB of the 500MB used at the
peak of image-update -n was action and plan data.
Cheers,
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
