v0.35.1

Pressing record was racing the model load, and losing

Last release put a number on the complaint that starting a meeting is
slow — 2977 ms — and stopped there. This one takes it apart.

Where the time was going, on this machine:

pressed straight away	3489 ms — model built after the press: 2907 ms
pressed 2 s after opening	347 ms
pressed 5 s after opening	298 ms
model already prepared	245 ms

So Summo's habit of preparing the model ahead of time works — ten times
over. The problem was that it is only prepared for the first couple of
seconds after you open the app, which is precisely when somebody who
opened Summo in order to record presses record.

Two things were wrong, and neither was visible from anywhere.

Pressing during the preparation started a second one. Summo knew
what it was holding and not what was coming, so a press mid-build
found nothing and loaded its own copy beside the one already being
built — two of them competing for the same cores, and a few hundred
megabytes that existed for no reason. Now the press waits for the model
already on its way.

The preparation started too late. It began when the record card
appeared on screen. Summo can know sooner: the request for the app's own
page is the first sign somebody is here, seconds before the interface has
finished loading. A Summo nobody has opened still holds nothing.

Afterwards:

pressed straight away	3000 ms
pressed 2 s after opening	269 ms

If you take even a moment between opening Summo and pressing record —
reading the screen, picking a language — it now starts in about a third
of a second. Pressing the instant the window appears still waits for the
model, and that wait is now 2.9 seconds once instead of twice over.

Making the model itself build faster is a separate piece of work. Saying
so is better than a release note that implies the number is finished.