next.js

9cee46cd - [turbopack] Encode task storage directly during persistence (skip clone) (#89412)

[turbopack] Encode task storage directly during persistence (skip clone) (#89412) # Don't clone TaskStorage objects when snapshotting the database ## What Instead of cloning `TaskStorage` objects when preparing to snapshot, we directly encode from a reference to the `TaskStorage` in the backend storage map. ## Why From a performance profile of `save_snapshot`, I observed that ~22% of the time was spent in `clone_meta_snapshot` or `clone_data_snapshot`, while ~28% of the time was spent in `encode_task_data`. The whole reason we are cloning is so we can drop the lock on the dashmap shard while encoding. In principle this makes sense, however: * We are only holding *read* locks on the dashmap, so we don't block other encoding threads * Holding the read locks for slightly longer will just slow down racing writing threads, but those are rare and already incur a high cost due to the extra cloning in `track_modification`. So slowing them down isn't too risky. ## Perf On a vercel-site cold build i don't actually see a real change in persistence time Before: 6.6s 7.8s 7.1s After: 6.9s 6.6s 7.2s So we are saving cpu time and allocations from this change but the overall task is bound on IO, so we should really only expect a win on more CPU constrained systems.