Danek Duvall wrote:
On Thu, Apr 16, 2009 at 01:09:38AM -0500, Shawn Walker wrote:
http://cr.opensolaris.org/~swalker/pkg-2557/
Looks good, generally.
Could you post the first dozen or so lines of your new cache file, or put
it up on cr.os.o?
http://cr.opensolaris.org/~swalker/pkg-2557/catalog_cache
catalog.py:
- Do we really need both cache_fmri() and fast_cache_fmri()? If nothing
else, since they're both building up the same structure, there's no
reason to duplicate the docstring. And cache_fmri() could do the
pre-chewing necessary to just use fast_cache_fmri(), no?
I'll trim the docstring, but they are both necessary.
The key differences are:
1) fast_cache_fmri does not do a bisect.insort() when adding cache
entries; it expects the caller to provide the data in sorted order
2) fast_cache_fmri expects fmri.version as a string as an extra
parameter to avoid the significant overhead of turning a version object
into a string (since in the cache load case we have the string from the
file, this is a win). I confirmed this using dtrace profiling.
The point of fast_cache_fmri was to allow cache loads to skip the
consistency, sorting, and type conversion overhead of cache_fmri.
image.py:
- line 1868: Would this be too crazy: "for lnum, line in enumerate(f):"?
Or even
for lnum, line in (i + 3, l.strip() for i, l in enumerate(f)):
Neat! So changed.
t_pkg_list.py:
- line 362,363: delete
Actually, those should be uncommented. Test only does half of what I
want without them :) Oops.
Cheers,
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
