[Aptitude-devel] Review of 298143

[Piotr Galiszewski]

2010/8/3 Piotr Galiszewski <piotr at galiszewski.pl>:
> 2010/8/3 Daniel Burrows <dburrows at debian.org>:
>>> +      package_filters_model::package_filters_model(QObject *parent)
>>> +        enum search_by
>>> +        {
>>> +          /** \brief searched_text is searched only in package name. */
>>> +          search_by_name = 0,
>>> +          /** \brief searched_text is searched in package name and package descriptions. */
>>> +          search_by_name_and_description = 1,
>>> +          /** \brief searched_text is searched in package maintainer name */
>>> +          search_by_maintainer = 2,
>>> +          /** \brief searched_text is searched only in all available package versions */
>>> +          search_by_version = 3
>>> +                            };
>>
>>  Doesn't this basically reimplement a small section of the match
>> patterns?  Please don't do that.  I'm not going to comment further on
>> this class unless you can convince me it should exist. :-)
>>
>
> Yes it is. It is used for fast searching for non advanced users. There
> is a edit box where user is typing text and category combobox, when
> user selects where the search should be run. I had written this before
> I looked on match patterns. Probably they also can be used (I can
> create pattern when user change text and create new matches_filter -
> matches filter is added in one of the later patches). The speed
> comparison is one questions (I really have to create some benchmarks
> ASAP and posts some result - searching be description will be the best
> test case). I can create pattern in code, when typed text is different
> than "~" and "?"
>

At least I have some real numbers to show ;) . I have tested all
currently supported "simple" search patterns. All code that was used
for this purpose is in 002.2 branch on gitorious. To get reliable
results I did 3 identical searches in each test (Whole patterns was
copied so there were no lazy loading in the meantime). Results:

1) searching by name:

a) simple (kadu):
0.073

b) aptitude patterns (?name(kadu)):
0.08


2) searching by name and description:

a) simple (kadu):
1.127 (first search took 1.57 and each later about 0.91)

b) aptitude patterns (?description(kadu) | name(kadu))
1.05


3) searching by maintainer:

a) simple (Patryk Cisek):
0.27 (first search took 0.51 and each later about 0.15)

b) aptitude patterns (?maintainer(Patryk Cisek))
0.44


4) searching by all versions:

a) simple (0.6.5.4):
0.09 (first search took 0.12 and each later about 0.035)

b) aptitude patterns (?any-version(0.6.5.4))
0.09

As expected search results were always the same ;) For later searches
lazy loading gives some improvements, but first search is always
longer. I do not know if manual creating of patterns will give some
visible improvements.

To sum up, On my machine lazy loading gives some improvements, but the
numbers are always small, so improvements is not big (and there is
always penalty during first search). How it will work on slower
machines I have no idea (my old computer died 6 months ago)

I am looking forward to read your opinions if it is worth to use
custom searching in this case (probably no). Now I am coming back to
normal code rewriting ;)

>>  Daniel
>>
>> _______________________________________________
>> Aptitude-devel mailing list
>> Aptitude-devel at lists.alioth.debian.org
>> http://lists.alioth.debian.org/mailman/listinfo/aptitude-devel
>>
>
> --
> Regards
> Piotr Galiszewski
>
-- 
Regards
Piotr Galiszewski