On Tue, 2005-10-25 at 10:13 +0200, Artem Baguinski wrote:
> On 25/10/05, James Livingston <jrl ids org au> wrote:
> > <fuzz matching>
> > The first attached patch (written by someone whose name I don't know)
> > does 1, half of 2, and 3; whereas the second patch only does 1. My from
> > quick tests, the second patch is actually faster than what RB does now,
> > because it only goes through each entry once, rather than going through
> > four times and them merging.
> >
> > If we want 1 (and possibly 2) I think the second patch should suffice;
> > if we want 3, I think we should merge the two patches.
>
>
> what about the first patch's speed ?
As a note, the majority of time taken when searching is actually spent
determining column sizes; which is bug 312122, and is next on my list
for "bugzilla roundup". If anyone is planning on doing benchmarking, do
so with the patch from that bug applied, because otherwise it will
obscure any actual speed differences from search box changes.
The patch as-is is noticeably slower than the second, however:
a) the punctuation removal is done at load-time not run-time (so it
doesn't affect speed), and could easily to added to the second patch.
b) there are several easy optimisations that could be applied to the
patch (which were done in the second).
With those optimisation done, it shouldn't be /that/ much slower then
not having it - but it will probably be slightly slower.
I guess the real question is whether we want "fuzzy matching" that can
ignore small differences or not. If we do, we should use the first patch
with optimisation; if not we should use the second patch, possibly with
punctuation removal.
> imho, it's important that search works fast. i'm really pleased with
> how it works now, if a patch makes it even faster I'll be even happier
As I mentioned above, the column-sizing problem makes searching,
re-sorting and loading _much_ slower. I have a reasonable size library,
with a lot of automatic playlists, and applying to patch from 312122
decreases the load-time of Rhythmbox from 9.5 seconds to ~1.5.
> do smart playlists use the same search?
What searching with "something" does is equivalent of an automatic
playlist which is:
Match any of the following
Title contains "something"
Artist contains "something"
Album contains "something"
Genre contains "something"
which works by running all four separately, and then merging them
together.
The second patch (as well as doing words separately) changes this by
adding a new "search" property, which allows it to match all four at
once - which is why it is faster that RB is currently.
Cheers,
James "Doc" Livingston
--
To bowl a maiden over:
i. Remove Cover and Extra Cover.
ii. Move fine leg to square leg.
Hmm, I can't seem to think of a way to finish this. -- Sid on RHOD
Attachment:
signature.asc
Description: This is a digitally signed message part