We don't have a strategy for determining whether the performance of immutable is acceptable. On the original repo, Lee did the manual work of deciding whether the performance was acceptable by pushing back on PRs that he knew to be slow.
One strategy is the "don't regress" strategy. I don't think this is a good strategy because the initial performance was somewhat arbitrary and the goals were not clearly defined. The advantage to this approach is that it's simple.
The dependability of the current bench-marking code is also not certain. The code is run in a VM context and when running bench-marking with the same exact code, it's not uncommon to see differences that exceed 10%.
One way to do it is to take a free api response (like pokemon api or something like this) which will have a real case object and from this we can test atleast fromJS and toJS use case
The problem
We don't have a strategy for determining whether the performance of immutable is acceptable. On the original repo, Lee did the manual work of deciding whether the performance was acceptable by pushing back on PRs that he knew to be slow.
One strategy is the "don't regress" strategy. I don't think this is a good strategy because the initial performance was somewhat arbitrary and the goals were not clearly defined. The advantage to this approach is that it's simple.
The dependability of the current bench-marking code is also not certain. The code is run in a VM context and when running bench-marking with the same exact code, it's not uncommon to see differences that exceed 10%.
We would also like to make the bench-marking automatic in CI (see https://github.com/immutable-js-oss/immutable-js/issues/208) so that this work doesn't have to be manual and we catch problematic code before the PR gets merged.
(See https://github.com/immutable-js-oss/immutable-js/issues/210, https://github.com/immutable-js-oss/immutable-js/issues/212, and https://github.com/immutable-js-oss/immutable-js/issues/213 for more context.)
Brainstorming