[cgijoe]

> Next: skip Chromium startup > This is complex, as a running browser has open devices, timers, graphics state, network state, and fingerprint state.

Hmm, can't you just keep a set of browsers already running, like a warm pool, ready to assign to an incoming request? The latency would be close to zero for the user. You'd need some prediction logic to expand / contract the warm pool based on traffic patterns, but that seems like the easiest solution to me.

[Reformedot]

Yes, warm pool work, but our goal is to replace them at all.

Warm pools are nice but at the end they also consume resources, And you need to always keep the pool warm, starting browsers to balance, etc...

With the upcoming changes we will keep Chromium startup and the VM will be ready in 50ms, defeating warm pools at all

Also some customers need special parameters and features, increasing warm pools complexity. The happy path will be fast but the edge case will be extremely slow , and we want to guarantee fast speeds to matter which features you need on the requested browser.

[tmzt]

Do you see much of a difference between started Chromium instances with the same configuration in terms of the contents of allocated memory? Are they deterministic?

If not, could you template the memory and apply runtime patches (like timers or other initialized values) before releasing the process to run?

Would forcing the isolates to allocate memory better help at all, such as reducing fragmentation making your 2MB page sizes more effective?

[hallway_monitor]

I think you mean “completely” instead of “at all”. Also, very cool innovative tech you are working on!