Report to users publicly results of: Test Terminal in low-memory; slow hard disk conditions, measure/reduce working set, minimize number of used shared libraries; binary size

In top bar we have + and v buttons.

After not using Terminal for some time (the app was opened, but not used, e.g. after recovery from hibernation), sometimes there're up to 2-3 seconds passing between clicking on v and context menu drop down appearing. Maybe it's delay for reading "settings.json" or loading memory pages into physical mem and O.S. being slow, but it'd be nice to have some guarantees on this drop down appearing (it'd better say loading if this can take a lot of time).

Same for + button. It takes me up to 5 seconds hanging before the tab appears (I'm not even talking of the title being shown and WSLv1 bash started).

After I've used these buttons couple times, they become faster, but still lag noticeably:
+ button maybe takes up to 100-200ms (judging by eye)
v has some 50-100ms delay

I wonder if these can be optimized to appear instantly and then do some loading, then one has a feeling that terminal does not hang and is doing some work.

It'd also be good if new tab instantly prints some temporary title, before the shell loads. Currently it's empty for up to 1 second (time of hanging + loading the shell inside the tab).

This is on version: 0.11.1333.0

It would also be nice to have these delays printed somewhere in the logs (maybe if some debugging mode is enabled), so we can easily pull them out, understanding that time-to-rendering may be hard to extract from the UI framework. But it'd be good to have for diagnostics, since terminal must be super-fast. E.g. I stopped using calc.exe and Windows Photo Viewer, since they take up to 5-10 seconds to load and render (probably because of using slow UI framework and requiring a lot of libraries loaded from disk), so I want my terminal + python loading fast for calculation needs :)

cc @DHowett-MSFT

No files or tests are named. Reproduce the + and v delays after hibernation under low-memory and slow-disk conditions, then measure startup time, working set, and shared-library use. Done means the measurements and optimization results are reported publicly, with useful loading or diagnostic behavior documented.