Object.freeze and Performance

See original GitHub issue

This is a very rudimentary test, but I think a large cause of performance penalties in Automerge might stem from the use of Object.freeze. I made a quick fork that removes these calls called hot-automerge and, similar to performance ticket #89 I ran a test with 10,000 inserts:

automerge profile 10000 inserts: 55546.893ms
hot-automerge profile 10000 inserts: 4051.241ms

That gives about a ~90% performance improvement. The fork is available here. Direct JSPerf tests on Object.freeze show about a ~45% performance penalty from use—presumably the difference comes from multiple calls.

Like the last performance tester, there could totally be something I’m missing here and I could totally be holding it wrong. If so, I’d love to know how because this library is incredible, and a performant, general-purpose, open-source multiplayer library is something the JS ecosystem very much needs. The future’s collaborative, after all.

Issue Analytics

State:
Created 4 years ago
Reactions:10
Comments:13 (8 by maintainers)

Top GitHub Comments

2reactions

eptcommented, Jul 13, 2019

Automerge 0.11.0 includes #179, which disables the use of Object.freeze by default, and thus works around the performance issue. Applications that want to continue using Object.freeze can pass the option {freeze: true} to Automerge.init(), Automerge.from(), or Automerge.load().

2reactions

eptcommented, Jul 3, 2019

On the other hand, bug-prone by default isn’t great either. ¯\_(ツ)_/¯ I hope that the performance problem will turn out to be temporary, and that we can look forward to a V8 patch that will fix it.

Anyway, we can turn off freezing by default for now, and then re-enable it in the future when it no longer incurs such a performance hit. To that end I have put up PR #179, which disables the use of Object.freeze by default.