[Reformedot]

Oh my bad. You mean warm pools then. That works, yes, but you need to maintain that warm pool, which might not be ready if we receive a big burst of demand

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.

[latchkey]

if people want custom features, then of course there is a cost to that. but if the majority of your customers are running on defaults, then there is a benefit. yes, it creates other issues, such as pool management, and if you do that wrong and you can't predict capacity well enough, then people get your "slow" path. but, overall, my experience is that the warm pools are extremely well regarded and not something that most people think of.

[otterley]

> case in point, it took me saying the same thing twice, for you to catch on

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.

[latchkey]

Sure, you're right. I edited to remove that bit. Thanks for calling me out. I was getting frustrated for having felt like I was extremely clear in what I wrote and the person kept repeating something that I had clarified.

> 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.

[otterley]

It depends on how you think about spare capacity on your hardware. They're an opportunity cost. Every idle cycle and bit of unallocated memory could be spent doing something else valuable. Consider the most extreme example of GPUs: CoreWeave was founded by repurposing nearly-useless GPUs their founders had on hand to mine Bitcoin (correction: Ethereum) that was obsoleted by ASICs and other specialized mining hardware (correction: transition to proof of stake).

Besides, they did say they were running on EC2, which charges by the second.

[latchkey]

Your CW analogy is wonky since that isn't how it went down. You know my name (I don't know yours. edit: Michael), so you should know a bit more about my history in the space too, right? I can explain it out, but afraid of either being called names, or just not being worth it to you (or me for that matter).

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.

[otterley]

You're right to call me out on the facts about CW as the story's a bit different from what I remembered from reading an article about them a few months back (https://www.wired.com/story/coreweave-scrappy-cryptominer-mu...).

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.