Performance

Measure on your hardware, treat these as shape#

Numbers were taken in the repository's environment — Editor, EditMode tests, in-memory storage, Unity 6000.6.0f1, Intel Core i9-14900K — over a representative model of 2000 objects producing a 91 KB document. They are printed by the Performance test category as [NF.Perf] <name>: <ms>, so you can reproduce them where it matters: Window → General → Test Runner → EditMode → right-click the Performance category → Run. Verified

In an IL2CPP release player (real disk, read-back verification on, compression and encryption on):

What the numbers say#

• Autosave is free when nothing changes. 0.03 ms per frame, and the test asserts that a long debounce produces no writes during the measurement, so it is real overhead rather than coincidence.
• Compression often pays for itself. Deflate is faster end to end here, because a 15× smaller payload costs less to hash, encrypt and write.
• The framework's plumbing is not the cost. Integrity, compression and encryption over 2000 objects are single-digit milliseconds; the term no library controls is the device's write throughput.
• A player save costs more than an Editor save because it includes read-back verification and a backup copy on real storage — the two features that catch a bad write.

Should manual saves move off the calling thread?#

Partly, and only where it is safe. The projection cannot move; everything after it can. If your save is small, the default is right — an offload costs a thread-pool hop and buys nothing. If your save is large enough that the frame drops, turn on Storage.OffloadWritesToThreadPool and measure again with the category above.

Next#

• Threading — the rules behind the numbers.
• Large saves — when the snapshot itself is the problem.
• Configuration reference — the settings these numbers come from.