@Janne252 Can you be a little more precise please? What lack to you mean? I see a short time of 'Loading...' which is basically what it takes to call all providers and to build the completion model but from then on I don't see any lack when typing

Please open dev tools, and run a CPU profile for the scenario that is slow for you. That should allow us to understand this bestter

@jrieken Absolutely. Here's 2 recordings that should demonstrate the issue:

Without the massive CompletionItemProvider:

With the massive CompletionItemProvider:

The lag is most noticeable while typing multiple short words, like passing local variables to a function call. Perhaps I'm over-exaggerating the issue a bit.

Edit: Since the gifts seem to automatically play & loop, I suppose it's best to open each individual .gif in a new tab and watch it from the beginning.

Ok, I can reproduce but not as easy as you can. Do you have the editor.quickSuggestionsDelay-setting?

I'll see how this can be made faster on our side, basically we are still filtering the list of 6000+ items when the next character wants to be inserted. We should be faster (or cancel earlier) but on your side you could also return less suggestion if that is possible

No, I don't have editor.quickSuggestionsDelay set. It would be great if the process can be made faster. It's a bit problematic when the public API is so ridiculously long and with standard lua, they are all exposed in the global namespace, so reducing the number of returned suggestions is not really possible.

Yeah, I will make it faster and already found one or two things. To validate my theories, I would be helpful if you can create profile and share it with me. Do the following

• hit 'F1 > Developer Tools'
• in there select 'Profiles' and start a 'CPU profile'
• type with suggestions and lack for a few seconds
• stop the profiler, save, and share it the profile with me

Thanks

CPU-20170118T182734.zip

For reference, I typed the following text and then waited for about 5 seconds before ending the recording:
This is a test and the test goes on and on and on. Now pausing.

Things we should look into

• debounce filtering while typing
• first filter, then sort (when retrieving results)
• run object track logic inside deserialise logic (when retrieving results)
• improve IPC communication performance (500ms are spend sending/receiving items)

@Janne252 So far I have the communication between the main side and the extension host a lot faster. You should feel this when suggestions are requested freshly for a new word. Also I have made small improvements in how often and how we filter. That should make a small difference when we filter down the 6000+ suggestions against the word you are just typing... The changes will be in tomorrows insiders build and I'd be happy to get some early feedback.

@jrieken How do I know when a new insiders build is out?
The date suggests that I have the today's version.

That's good. There is an update every day and you should already have some performance improvements. It would be helpful if you can do another profiler run

@jrieken Here you go: CPU-20170125T172131.zip

The match/score performance will be tackled in #22153

Closing this as scoring, sending/receiving items, and finally garbage collection spying has been improved. This has served as a great issue to tackle various issues and I hope things are better now. I will keep the sample extensions for the future and I will continue with performance work here and there.