Two reasons: we use the list widget for IntelliSense which is super fast and does not have high update cost when updating the tree. Second, quick open actually limits the number of results to some value, at least for file search.

CPU trace attached:
CPU-20170207T183917.cpuprofile.zip

The original slowness is no longer there (the one from the tree), when I now test it with 10000 elements the majority of time is spend in QuickOpenModel.compare() where we check if a element is a match for a given search string.

So bottom line, switching to the list widget as we do in IntelliSense will not yield much better results imho.

@isidorn this might be resolved if we switch to using a list for quick pick.

Closing as duplicate of using a list for quick pick. Till then this is just a consequence of us using a tree which we do not plan to change afaik
fyi @chrmarti

Most time is spent comparing entries.

We closed this issue because we don't plan to address it in the foreseeable future. You can find more detailed information about our decision-making process here. If you disagree and feel that this issue is crucial: We are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding and happy coding!