Performance problem in completions(e.g. tabopen) when 'Smart Completions' contains long URL.

[Mine02C4]

Suddenly one day, Firefox stops for a few seconds at the completion in 'tabopen', and tried to profiling.

This screenshot is the result.

https://github.com/vimperator/vimperator-labs/blob/master/common/content/completion.js#L425

This line has been called very much. The number is proportional to the length of a URL, and the time for each is proportional to the length, so the total time is proportional to the squares of the length.

My native language is Japanese, so I access well to pages whose URL contains multi-byte characters.Because it has been displayed in the completion, this performance issue surfaced.

However, I do not fully understand the structure of this part, I cannot write a patch to resolve this problem.

[maxauthority]

The problem is the "f" part in the "complete" option which includes local
files.
We'll remove that from the default value in future.

For now, do a:
:set complete-=f (or :set complete=sl , if -=f does not work).
(and put it in your .vimperatorrc).

Hope that helps,
Martin

[Mine02C4]

I already 'set complete=sl' in vimperatorrc.
I thought this problem that's different from #8 . Actually, this problem is no longer after removing the long URL from the history.

[maxauthority]

Ah I see, yeah that might be a different problem, especially if the fixCase() function is called too often.

Actually the whole completion code is unnecessarily complex for supporting many old vim features (like "wildmode"). If you don't understand the current structure, you are also free to provide a completely new, modern vimperator completion system :)

[caisui]

I wrote patch.
this patch is performance up except wildmode=longest.

https://gist.github.com/caisui/efddb6a16cb2ede5284e

Moreover, I think "longestSubstring" is not reference from somewhere.
but, I understand little about Completion.

To reproduce

1. wildmode=list:full
2. tabopen about:blank
3. js content.location.href+="#"+Array(1000).join("a")
4. buffer aa

[maxauthority]

I think we should remove the wildmode=longest anyway.

For places like URLs we could add that when it makes sense (like to have
google.com completed instead of google.com/foo/bla/jjklj as the first
hit), but for most other things it's just not worth the complexity. That
would probably make the whole completion code much simpler.

The only place where it could make sense might be :js completion, but
again, by adding the entries in a meaningful manner, I am sure also the
default completion of the first match is working well.

[maxauthority]

@caisui: Interesting fix, but if it works, we should of course commit it.
Can you either send me a git pull request (which is much simpler than
handling patches), or just commit it yourself this time?

Thanks, Martin

On Fri, Aug 8, 2014 at 2:51 PM, Martin Stubenschrott <
stubenschrott@vimperator.org> wrote:

I think we should remove the wildmode=longest anyway.

For places like URLs we could add that when it makes sense (like to have
google.com completed instead of google.com/foo/bla/jjklj as the first
hit), but for most other things it's just not worth the complexity. That
would probably make the whole completion code much simpler.

The only place where it could make sense might be :js completion, but
again, by adding the entries in a meaningful manner, I am sure also the
default completion of the first match is working well.

[Mine02C4]

In my environment, caisui's patch works well. @caisui Would you send the project a git pull request?

[MoSal]

I've just got bitten by this bug.
Never thought using Google Translate would cause an interesting post-effect like this.

Anyway, I can confirm that caisui's patch fixes the bug.

[Mine02C4]

Fixed by #36