[zypp-devel] Re: [zypp-commit] r8127 - in /branches/tmp/ma/jump_sat/libzypp/zypp: ./ base/ parser/susetags/ pool/ sat/ sat/detail/
Hi, On Tue, 18 Dec 2007, mlandres@svn.opensuse.org wrote:
Author: mlandres Date: Tue Dec 18 21:49:35 2007 New Revision: 8127
URL: http://svn.opensuse.org/viewcvs/zypp?rev=8127&view=rev Log: - Changed ResKind implementation to use IdStr. - split Solvable ident into kind/name - map src/nosrc Solvables to kind(SrcPackage) and arch(noarch)
I think it would be better if either libzypp would do away with the Solvable kind altogether, or implement this so that it doesn't take up any space in the libzypp wrapper of the sat Solvable structure. I can't really see how fantastically usefull the kind is to deserve it having an own member. The only uses I can imagine are of the type "give me only Patches" or "don't search Patterns" and the like. The old solver also uses them in Dependencies, but let's ignore that, as it's going away. So, in all cases you already have a Solvable, hence the complete SAT Name, which includes the "type". I think it would be better to compute the kind from that whenever it's necessary, instead of storing it. It can be done quite fast when we assume that ':' doesn't occur normally in a name (we can assume that): int solv2kind (Solvable *s) { if (s->arch == ARCH_SRC || s->arch == ARCH_NOSRC) return KIND_SOURCEPACK; const char *name = id2str(s->name); // make sure we have four characters if (!(name[0] && name[1] && name[2] && name[3])) return KIND_PACKAGE; int len = 0; int kind = 0; switch (name[3]) { // we look at the fourth character --------v case 'm': len = 4; kind = KIND_ATOM; break; // atom case 'g': len = 8; kind = KIND_LANGUAGE; break; // language case 's': len = 7; kind = KIND_MESSAGE; break; // message case 'c': len = 5; kind = KIND_PATCH; break; // patch case 't': len = 7; kind = KIND_PATTERN; break; // pattern case 'd': len = 7; kind = KIND_PRODUCT; break; // product case 'e': len = 9; kind = KIND_SELECTION; break; // selection case 'i': len = 6; kind = KIND_SCRIPT; break; // script default: return KIND_PACKAGE; } int i; // make sure string doesn't end before the position of the ':' for (i = 4; i < len && name[i]; i++) ; if (i == len && name[i] == ':') return kind; return KIND_PACKAGE; } This needs to touch just one cache line of something which most probably is in cache already (the name) and hence is only slower by a couple of cycles compared to directly having the kind stored away. But it saves half the size of Solvables. Ciao, Michael. -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
On Tue, Dec 18, Michael Matz wrote:
I think it would be better if either libzypp would do away with the Solvable kind altogether, or implement this so that it doesn't take up any space in the libzypp wrapper of the sat Solvable structure.
I told you that I don't intend to store additional data inside the solvable. So wait until the code is done. ;)
I can't really see how fantastically usefull the kind is to deserve it having an own member. The only uses I can imagine are of the type "give me only Patches" or "don't search Patterns" and the like.
This is what the UIs frequently do. And they don't want the kind prefix in a name. Thats why we'll provide an accessor for both. Huha will kill us if his pattern view looks like: pattern:kde 10.3-155 pattern:kde4_basis 10.3-155 pattern:kde_basis 10.3-155 pattern:kde_basis_opt 10.3-155 pattern:kde_games 10.3-155 pattern:kde_ide 10.3-155 pattern:kde_imaging 10.3-155 pattern:kde_imaging_opt 10.3-155 pattern:kde_internet 10.3-155 pattern:kde_laptop 10.3-155 pattern:kde_multimedia 10.3-155 pattern:kde_office 10.3-155 pattern:kde_office_opt 10.3-155 pattern:kde_utilities 10.3-155 pattern:kde_xgl 10.3-155 -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres YaST Development ma@novell.com SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0 +------------------------------------------------------------------+ -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
* Michael Andres <ma@suse.de> [Dec 19. 2007 12:51]:
This is what the UIs frequently do. And they don't want the kind prefix in a name. Thats why we'll provide an accessor for both. Huha will kill us if his pattern view looks like:
pattern:kde 10.3-155
Contrary to solving dependencies, the user interface doesn't need to be optimized to the last nanosecond. So I'd assume a strchr(name, ':'), done in the application layer, should be acceptable here. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
On Wednesday 19 December 2007 12:54, Klaus Kaempf wrote:
Contrary to solving dependencies, the user interface doesn't need to be optimized to the last nanosecond.
Says he who complains about searching being too slow... CU -- Stefan Hundhammer <sh@suse.de> Penguin by conviction. YaST2 Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Nürnberg, Germany -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Hi, On Wed, 19 Dec 2007, Stefan Hundhammer wrote:
Contrary to solving dependencies, the user interface doesn't need to be optimized to the last nanosecond.
Says he who complains about searching being too slow...
That's not because the UI is too slow, but because the way the search is implemented in libzypp is. sqlite isn't optimized for searching strings in the database. This particular detail (the kind thingy) can really be implemented via code instead of data. Btw.: % time ./dumpattr -bi downloading < test.attr > /dev/null real 0m0.170s user 0m0.164s sys 0m0.004s This happens to search for the string "downloading" (case insensitive) in all textual attributes of the 10.3 DVD biarch Repository, and it's compiled without optimization. Ciao, Michael. -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
On Wednesday 19 December 2007 15:37:29 Michael Matz wrote:
That's not because the UI is too slow, but because the way the search is implemented in libzypp is. sqlite isn't optimized for searching strings in the database. This particular detail (the kind thingy) can really be implemented via code instead of data.
That is because UI search is a iteration over the pool. No sql is used and the db is loaded in memory completely before (so the time is paid once at start up). Then during the iteration, the string is compared against every attribute of the resolvable, which is retrieved from the db on the fly (as they are not in memory), which results in one sql query per comparision. zypper uses sql for searchng and appart from reading the rpm db search is really fast, only 1 query is done. Duncan -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
participants (5)
-
Duncan Mac-Vicar Prett
-
Klaus Kaempf
-
Michael Andres
-
Michael Matz
-
Stefan Hundhammer