Limit maximum items in list or provide way to hide items.

[jordwalke]

There's an existing issue to allow omitting commands in the palette. I like the idea behind that feature request, but I want to make a more broad feature request: Make it so that the command palette isn't slow and sluggish when plugins add many commands. Issue #35 is just one potential solution so please close this issue and merge it with the other one if you think that #35 is the best approach. But there are other ways to fulfill my specific performance based feature request - you may truncate the list length at a configurable amount (ideally defaulted to some number like 50.

This is actually an important feature because one of the most popular (and imho important) packages for Atom (vim-mode-plus) necessarily implements many commands and these are all added to the command pallet. This makes the command pallet sluggish to open. I don't mind there being too many entries in the list from a searchability standpoint - typing filters effectively. I mind the slugishness when opening the command pallet and Atom feeling more bulky than it actually is due to VMP being such a beloved (and frequently installed) plugin.

Having this problem fixed by default out of the box when installing vmp is important because I'd love to be able to recommend Atom + VMP as a viable solution for long-time Vimmers, and know that the default out of box experience is going to feel great.

Another alternative solution is to incrementally render more rows, so that the initial opening is not blocked on rendering all of them. This is more complicated and probably doesn't improve the situation as effectively because it still renders many rows that are never seen by the user and creates a bunch of garbage for the system to manage that didn't provide much value. I doubt anyone opens the command palette and uses the down arrow to browser over 30, let alone 50 entries in the list - a compliment to the general user experience of the type-search experience.

[nathansobo]

Now that we allow commands to be hidden in #92 and are caching element items in #94, can this be closed? Or is the palette still sluggish to open when there are lots of commands? @jarle do you have thoughts on this?

[jarle]

Recent PRs have at least narrowed the problem down to the initial command-palette toggle. @t9md timed this to ~100ms(with several community packages installed) in #81, which I think is acceptable. Based on that, I think it is fair to close this issue. If opening the palette continues to feel sluggish for some after these changes, it might be interesting to collect some numbers on how long the toggle actually takes on their hardware.

[t9md]

I checked, latest master(with caching feature enabled).

In short, although it reduce some perf issue, I still feel lag.
What I'm focusing(I believe it sync with @jordwalke 's intention) is initial-open response time.

Work flow i'm imagining is

• Open atom window and immediately hit cmd-shift-p to invoke some command.
• After a while open another new atom window and hit cmd-shift-p immediately and so on.

Initial palette open lag is most important and caching is nothing to do with that(as far as I understand).
Still limiting maxResults is really effective, it reduce items to render(reduce num of element attached to DOM).

As experiment I reproduced quick time-measure I did in #81 with latest master.
Here is how I added code t9md#1.

• So in my local env with vim-mode-plus pkg + other pkg, total num of command reaches 738.
• Total time spent on 1st command-palette:toggle is 263ms(no limit) vs 93ms(max 20)
• This is big diff. When total ms exceeds 100ms, I can feel lag(I believe everyone can).

I will continued experiment to find apply maxResult without confusing user to reduce initial open response lag.

[jarle]

Thanks for benchmarking! I have implemented a solution in #97 where items are added incrementally. This change should significantly speed up launching the command palette.