Our BigInt implementation [uses mozilla::Span for bounds checking when accessing digits](https://searchfox.org/firefox-main/rev/54da8f6bfead7871ca89f2cb18323af5f00d9620/js/src/vm/BigIntType.h#96-107). Profiling the bigint-noble-ed25519 subtest in JS3, more than 25% of the total time is spent inside the two implementations of `digits()`. On my machine, V8 scores ~60 on this subtest. We score ~45. If I rewrite `digits` to index directly (without bounds checking) then our score increases to ~65. Adding `MOZ_RELEASE_ASSERT(idx < digitLength())` decreases that to ~55. I think part of the issue here may be [these asserts](https://searchfox.org/firefox-main/rev/54da8f6bfead7871ca89f2cb18323af5f00d9620/mfbt/Span.h#272,276) in extent_type (deep in the implementation of Span). At the very least, it seems reasonable to elide those. **js-perf-next**: Figure out how many release asserts we're comfortable removing here.
Bug 2005652 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Our BigInt implementation [uses mozilla::Span for bounds checking when accessing digits](https://searchfox.org/firefox-main/rev/54da8f6bfead7871ca89f2cb18323af5f00d9620/js/src/vm/BigIntType.h#96-107). Profiling the bigint-noble-ed25519 subtest in JS3, more than 25% of the total time is spent inside the two implementations of `digits()`. On my machine, V8 scores ~60 on this subtest. We score ~45. If I rewrite `digits` to index directly (without bounds checking) then our score increases to ~65. Adding `MOZ_RELEASE_ASSERT(idx < digitLength())` decreases that to ~55. I think part of the issue here may be ~[these asserts in extent_type](https://searchfox.org/firefox-main/rev/54da8f6bfead7871ca89f2cb18323af5f00d9620/mfbt/Span.h#272,276)~ [this assert in storage_type](https://searchfox.org/firefox-main/rev/54da8f6bfead7871ca89f2cb18323af5f00d9620/mfbt/Span.h#851) (deep in the implementation of Span; thanks to mccr8 for pointing out that my profile didn't match my link). At the very least, it seems reasonable to avoid that cost. **js-perf-next**: Figure out how many release asserts we're comfortable removing here.