jmr wrote:
Shawn - a few comments:
JR
Notably, the addition of the pending repository to the same system (an
extra 11,000 packages) resulted in an increase to 10M for the cpickle
cache, but only to 2.3M for the flat file. So long-term scalability
is better for the new method plus it uses less disk space and one less
module.
We are using cpickle for the PM cache.
Right; we've been using cPickle too. But it seems to have too much
overhead for a relatively simple data structure.
Finally, I also evaluated remove the catalog cache entirely since on
faster systems (such as my 3.0 GHz Core 2 Duo 8GB ram desktop) it
provides little performance benefit. However, on slower systems (such
as my Sony Vaio Core 2 Duo 2.4 GHz 2GB ram laptop) there was a
reduction in operation time as much as 1-3 seconds with the cache. As
such, it seems best to keep the cache for now or alter it to be
specialised later.
I would be very nervous about removing the cache at this late stage and
would like to carefully analyze the effect of doing so on the listing
operations we need to use in the GUI. So I am happy with the choice to
leave as is for 2009.06, but would be interested to see what
optimizations are possible for listing operations post 2009.06. This is
important if we are to remove all the private API calls from PM, UMN and
UM.
Right; Danek expressed the same concerns which is why the decision to
change the cache rather than remove it was made.
Cheers.
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
