So, one hypothesized road forward here is the consumption of cached native iterators created by `for-in`. I have built a very preliminary prototype patch that does exactly this to evaluate the potential win we could see here. It's built on top of the patch in Bug 1838529 to avoid the reallocation issues we'd seen elsewhere. In this prototype patch we directly consume the `for-in` cache if it exists; so the microbenchmark on this bug was tweaked to walk the object once with 'for-in' to prime that cached iterator. The prototype patch is not sound since we don't handle prototype properties at all; it merely says "if there's a pre-existing for-in iterator, put those properties in, then create the keys array." In this sense, this is almost the best case scenario we can hope for performance wise. The results are... underwhelming. ``` $ hyperfine '/home/matthew/unified/obj-opt-shell-nodebug-x86_64-pc-linux-gnu/dist/bin/js keys-benchmark.js' 'ENABLED=1 /home/matthew/unified/obj-opt-shell-nodebug-x86_64-pc-linux-gnu/dist/bin/js keys-benchmark.js' Benchmark 1: /home/matthew/unified/obj-opt-shell-nodebug-x86_64-pc-linux-gnu/dist/bin/js keys-benchmark.js Time (mean ± σ): 263.8 ms ± 1.0 ms [User: 265.3 ms, System: 7.6 ms] Range (min … max): 262.4 ms … 265.6 ms 11 runs Benchmark 2: ENABLED=1 /home/matthew/unified/obj-opt-shell-nodebug-x86_64-pc-linux-gnu/dist/bin/js keys-benchmark.js Time (mean ± σ): 221.7 ms ± 2.9 ms [User: 221.3 ms, System: 8.0 ms] Range (min … max): 217.7 ms … 228.9 ms 13 runs Summary 'ENABLED=1 /home/matthew/unified/obj-opt-shell-nodebug-x86_64-pc-linux-gnu/dist/bin/js keys-benchmark.js' ran 1.19 ± 0.02 times faster than '/home/matthew/unified/obj-opt-shell-nodebug-x86_64-pc-linux-gnu/dist/bin/js keys-benchmark.js' ``` So a 20% improvement on an already synthetic microbenchmark is all this gives us. Furthermore, we have more work to do in order to filter out prototype properties (fortunately, I think this is comparatively easy -- we can divide the range that comes out of our enumerators into 'own properties' and 'proto properties', so with a single index/offset we can disambiguate own vs proto properties).
Bug 1836679 Comment 7 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
So, one hypothesized road forward here is the consumption of cached native iterators created by `for-in`. I have built a very preliminary prototype patch that does exactly this to evaluate the potential win we could see here. It's built on top of the patch in Bug 1838529 to avoid the reallocation issues we'd seen elsewhere. In this prototype patch we directly consume the `for-in` cache if it exists; so the microbenchmark on this bug was tweaked to walk the object once with 'for-in' to prime that cached iterator. The prototype patch is not sound since we don't handle prototype properties at all; it merely says "if there's a pre-existing for-in iterator, put those properties in, then create the keys array." In this sense, this is almost the best case scenario we can hope for performance wise. The results are... underwhelming. ``` $ hyperfine '/home/matthew/unified/obj-opt-shell-nodebug-x86_64-pc-linux-gnu/dist/bin/js keys-benchmark.js' 'ENABLED=1 /home/matthew/unified/obj-opt-shell-nodebug-x86_64-pc-linux-gnu/dist/bin/js keys-benchmark.js' Benchmark 1: /home/matthew/unified/obj-opt-shell-nodebug-x86_64-pc-linux-gnu/dist/bin/js keys-benchmark.js Time (mean ± σ): 263.8 ms ± 1.0 ms [User: 265.3 ms, System: 7.6 ms] Range (min … max): 262.4 ms … 265.6 ms 11 runs Benchmark 2: ENABLED=1 /home/matthew/unified/obj-opt-shell-nodebug-x86_64-pc-linux-gnu/dist/bin/js keys-benchmark.js Time (mean ± σ): 221.7 ms ± 2.9 ms [User: 221.3 ms, System: 8.0 ms] Range (min … max): 217.7 ms … 228.9 ms 13 runs Summary 'ENABLED=1 /home/matthew/unified/obj-opt-shell-nodebug-x86_64-pc-linux-gnu/dist/bin/js keys-benchmark.js' ran 1.19 ± 0.02 times faster than '/home/matthew/unified/obj-opt-shell-nodebug-x86_64-pc-linux-gnu/dist/bin/js keys-benchmark.js' ``` So a 20% improvement on an already synthetic microbenchmark is all this gives us. Furthermore, we have more work to do in order to filter out prototype properties (fortunately, I think this is comparatively easy -- we can divide the range that comes out of our enumerators into 'own properties' and 'proto properties', so with a single index/offset we can disambiguate own vs proto properties). *Edit:* If anyone is interested, [here's a profile of the optimized case](https://share.firefox.dev/3panrw4)