On Thu 11 Sep 2008 at 11:34AM, Brock Pytlik wrote:
> >
> client.py:
> lines 76-79:
> I don't quite get the reason for this change
It's so that you can do error(e) where e is an exception. You can't
call lstrip() on an exception...
> line 161:
> Might it be better to record that a bad fmri has been encountered and
> continue trying them, so the user gets all the malformed fmris in one
> shot, rather than iteratively fixing one at a time?
I've fixed this and improved the messaging some more. Thanks!
> Just curious, how can you get illegal fmris after you've checked them in
> the client? I'm thinking specifically about places like line 1006-1020.
This is a kludge of sorts-- I chose to handle the exception here
because the API can throw it. Due to the check in check_fmri_args()
that should not happen, but I decided to go with a belt-and-suspenders
approach.
This is by no means perfect-- I think some more work is needed
to refactor the APIs to use "MatchingFmri" objects instead of
strings-- if you are passing an FMRI into the API (and not a string)
then there's no need for it to emit an IllegalFMRI exception at you!
> Other than that, it looks fine to me. Is there much performance hit
> we're taking on creating fmris or versions from this?
Yes, good question. We take a real hit in some paths that I fought
to make faster :(. Version hashing is 2x better than before, so that might
help in some places. Here are the numbers. This is in ops/second so more is
better:
TEST BASELINE NEW DIFF
dotsequence creation 304053 187323 -38.4%
dotsequence cmp 1 (v2 > v1) 7648805 8091249 5.8%
dotsequence cmp 2 (v1 > None) 7931574 8341976 5.2%
dotsequence cmp 3 (same) 11527373 11409832 -1.0%
dotsequence is_subsequence (true) 565101 562386 -0.5%
dotsequence is_subsequence (false) 1683886 1761824 4.6%
dotsequence to string 389704 393948 1.1%
version hash (tstamp) 427420 1296070 203.2%
version hash (no-tstamp) 432883 415187 -4.1%
fmri create 45660 32593 -28.6%
fmri create (no tstamp) 54021 36037 -33.3%
fmri create (no tstamp, no bld/branch) 63979 44139 -31.0%
fmri create (no ts, no bld, no orgn) 55054 37342 -32.2%
(I elided the rest, all are +-1%)
In practice, it appears that an image-update -nv is about the same.
'pkg list' is fractionally (less that 0.1 sec) slower.
'pkg list -a' looks to be about 0.2 seconds slower on my machine
(from 2.419 to 2.585s).
It'd be really nice to be faster. We can potentially:
- Break up the codepaths into "user fmris" (strictly syntax
checked) and "machine fmris" (presumed to be OK-- omit
package name checks, time validity checks, etc). This
requires greater coder discipline.
- Accelerate the syntax checking in C, perhaps, when we
have a chance.
Thanks,
-dp
--
Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
