[core] Implement Throttling Prioritized Package Loading (WIP - Open to Comment)

[confused-Techie]

After a new wave of concerns over Pulsar's startup time it got me thinking back to dubious concerns about how well Atom's old performance hacks are still holding up.

The one closest to my heart being the way we load packages during startup.

The status quo now is essentially:

• Preload bundled package's just prior to window startup
• Load all other packages simultaneously during startup

This PR aims to change this, if others are on board.

This PR would ditch the preload system entirely, with the amount of packages now bundled, I can't imagine this is really saving anyone time anymore. But more importantly, this PR would ditch loading all packages at once.

Instead using a throttled prioritization system. Where we assign a priority to all available packages, and load installed packages in waves, starting with the highest priority. The idea behind this hinges on the fact that not everyone uses Pulsar for the same tasks. Some users may never use markdown-preview just like some may never use language-c, so why do they both take up time during the startup when it wouldn't make any difference to the user if they started now or a few seconds later?

While this is most certainly a very rough draft, and I haven't ironed out all the details of prioritization, here's the goals I'd like to achieve with prioritization:

• Packages that contain important UI elements are always highest priority: tabs, status-bar, tree-view, etc
• Packages that are the currently active themes are always highest priority
• (If possible) the syntax highlighting for the currently open documents is always highest priority
• The priority of all items is configurable by the user, to ensure any oversight or unexpected usage is respected and available

While this is very likely not totally inclusive, and in it's current state is far from that, my initial testing is rather promising:

Below I've launched an installed copy of Pulsar v1.124.0 and v1.124.0-dev on Windows 10. I launched each version 5 times and recorded the time-cop values for certain startup metrics.

Before PR:

• Shell load time: 227ms, 243ms, 257ms, 261ms, 244ms :: Average: 246.4ms
• Window load time: 1422ms, 1347ms, 1356ms, 1336ms, 1449ms :: Average: 1,382ms
• Project load time: 81ms, 84ms, 79ms, 83ms, 90ms :: Average: 83.4ms
• Workspace load time: 278ms, 276ms, 272ms, 271ms, 320ms :: Average: 283.4ms

After PR:

• Shell load time: 311ms, 270ms, 260ms, 258ms, 257ms :: Average: 271.2ms
• Window load time: 814ms, 713ms, 701ms, 713ms, 708ms :: Average: 729.8ms
• Project load time: 98ms, 85ms, 86ms, 82ms, 90ms :: Average: 88.2ms
• Workspace load time: 53ms, 44ms, 42ms, 41ms, 41ms :: Average: 44.2ms

Results

• Shell load time: 246.4ms : 271.2ms = On average a 10% ms increase after this PR
• Window load time: 1,382ms : 729.8ms = On average a 47% ms decrease after this PR
• Project load time: 83.4ms : 88.2ms = On average a 5.7% ms increase after this PR
• Workspace load time: 283.4ms : 44.2ms = On average a 84.4% ms decrease after this PR

So while we can see these results do have some slight increases, if we in fact are removing on average 652.2ms or 47% of our Window load time, and removing on average 239.2ms or 84.4% of our Workspace load time, this seemingly could make a pretty big difference to our subset of users who are concerned about startup time. All the while giving us and our users much finer control of their startup experience.

---

Like I've mentioned several times, these ideas are very in progress, and are far from finalized. But after playing around with the code and seeing such a big difference, it seemed like a good idea to go ahead and post it, to get an idea of how we feel about a change as integral as this. So please feel free to share your ideas or thoughts, otherwise I'll continue trying to hone in on exact functionality here.