So there's no benefit on reusing the VM but not the browser. VM isolation is also important, customers can leave downloads and other files that should not be accessible for freshly created browsers on that same VM.
Keeping the browser open and warm is also a problem, not all customers require the same features. The same engineering required to fix that (modifying values with Chromium open), also fixes the post-chromium snapshot
VM takes 20ms to start, browser around 300ms. Post-Chromium snapshot is at 50ms end-to-end, defeating the benefits of the warm pool you suggest, that will be our next step.
Quit being a dick, Jon. It doesn't suit your stature.
At any rate, warm pools aren't cost free. If you overestimate demand, you'll waste too much money on idle resources.
> At any rate, warm pools aren't cost free. If you overestimate demand, you'll waste too much money on idle resources.
Depends on how you're running your business. If it is your hardware, it isn't much of an expense at the benefit for having a product that makes your customers happy.
Besides, they did say they were running on EC2, which charges by the second.
EC2 has preemptable and reserved pricing. It is possible to build autosizing solutions, this is what Google did with AppEngine and later GCP Functions/Cloud Run. Just like optimizing start times, it is also possible to optimize those idle resources. For me, I'd go with the idle resources as the lower hanging fruit over trying to shave ms off making things available on-demand, since it affects the customer experience first.
That said, I think you get the point about idle capital being waste. EC2 Spot Instances are a great example about how to turn that waste into revenue.