[MonoDevelop] Navigate to dialog item filter
mkrueger at novell.com
Mon Aug 2 09:43:00 EDT 2010
> The old algorithm is a bit slower, but it gives better search results.
> For example, try looking for 'ccommand'. The list you get using the old
> algorithm makes much more sense to me than what you get in the new one.
Some wouldn't be the problem it's only a bit - it'. Yes the old one
finds more matches - I know that,
But I want to know from the users which search cases should be matched -
I just don't believe that the substring matching in the navigate to
dialog should be different than that in the code completion.
I took the code completion algorithm as a start because of the speed.
For MD alone we match up to 141702 items - that's on my machine:
8623ms vs 128ms
I've implemented some caching algorithm that leaves us to match 90400
items. Thats still roughly 5200ms vs 84ms on my system - thats not a
bit slower - thats magnitudes slower. I tested this with the stand alone
version & took the MD numbers of items, it's hard to tell how long it
takes in monodevelop - could be more/could be less - but it's another
user experience when changing the algorithm. Thats why I've came up with
> Also, the new algorithm can't handle some queries. For example, if I try
> to look for CustomCommandCollection
> using the strings 'comcoll',
> ' or even 'commandcollection' I don't get any result.
> Those issues should be fixed before switching to the new algorithm.
This are two examples I would value as bug - I've not thought about that
case. They should match for the code completion as well.
I added them to the code completion bug unit tests. To match them I've
taken the other algorithm and used some optimizations and now it runs
the 90k items in around 2200ms - still there is room for improvement.
But by changing to the other algorithm 2 unit tests failed. (another
reason to use one matching subsytem)
The new matcher matches "AbCdEf" when a filter "bC" is given. And it
matches "DatabaseObject" when "DOB" is given - the latter may match (I
don't think it should - upper case should always force a word jump IMHO)
- but the bug report was about
"DatabaseObject" vs. "DatabaseObjectBase" - in that case
"DatabaseObjectBase" should be selected (however with "dob", "Dob" or
"DOb" the "DatabaseObject" is the better match).
Do you agree on these cases ? (I'm always open for ideas how to improve
the matching even more - the matching logic is an important part of the IDE)
I see no reason for using two algorithms, using two would mean:
A) We never find all those issues
B) Monodevelop behaves incosistent (different filters for code
If anyone has interrest in playing around how the subword matcher works
it's all in CompletionMatcher.cs - it's an easy class to change.
> El dg 01 de 08 de 2010 a les 18:21 +0200, en/na Mike Krüger va escriure:
>> I changed the navigate to dialog item filter - I had it a few versions
>> before - but then reverted it to the 'old' navigate to type/file filter.
>> (nobody recognized afaik)
>> But after that the navigate to dialog was very slow when filtering large
>> projects like the monodevelop one - (but nobody recognized that too).
>> Now I've changed it back to the completion filter - the code completion
>> uses a very easy greedy algorithm - the navigate to filter was more
>> complicated. (but I think it's more a matter of taste which one is more
>> I attached a small test file which compares the speed of the two
>> algorithms. Most of you know the filter from code completion - but I
>> want some feedback from our users about that issue.
>> I prefer the code completion filter alone for consistency reasons - I
>> like how it behaves& how to search items with that. It should behave
>> like the R# filter.
>> Monodevelop-list mailing list
>> Monodevelop-list at lists.ximian.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Monodevelop-list