Mailinglist Archive: zypp-devel (56 mails)
| < Previous | Next > |
Re: [zypp-devel] Re: [zypp-commit] r8127 - in /branches/tmp/ma/jump_sat/libzypp/zypp: ./ base/ parser/susetags/ pool/ sat/ sat/detail/
- From: Duncan Mac-Vicar Prett <dmacvicar@xxxxxxx>
- Date: Wed, 19 Dec 2007 16:11:16 +0100
- Message-id: <200712191611.17069.dmacvicar@xxxxxxx>
On Wednesday 19 December 2007 15:37:29 Michael Matz wrote:
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@xxxxxxxxxxxx
For additional commands, e-mail: zypp-devel+help@xxxxxxxxxxxx
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@xxxxxxxxxxxx
For additional commands, e-mail: zypp-devel+help@xxxxxxxxxxxx
| < Previous | Next > |