compiler/natives/src/strconv: Use js string conversion utilities to improve performance #786
Conversation
compiler/natives/src/strconv/atoi.go
Outdated
| if len(s) == 0 { | ||
| return 0, syntaxError(fnAtoi, s) | ||
| } | ||
| jsValue := js.Global.Call("Number", s, 10) |
There was a problem hiding this comment.
I believe JS's Number constructor is far more forgiving than Go's Atoi implementation. Is it therefore reasonable to validate that s contains only Go-acceptable numbers?
Some examples of values that Number() accepts but Atoi() should not:
- "0x10"
- "10.2"
- "0b11"
- "0o10"
There was a problem hiding this comment.
Probably should do some input validation first - if the resulting code is slower than just using Atoi directly I will probably remove this piece of code from the PR
There was a problem hiding this comment.
Validate doesn't seem to have hurt perf at all -- pushing up the changes.
There was a problem hiding this comment.
Looks like a good improvement. And glad to hear it doesn't have a noticeable impact on performance!
|
@shurcooL another optimization PR for you :) |
Conflicts: compiler/natives/fs_vfsdata.go
|
Superceded by #1101 |
Added native implemntations for Atoi and Itoa. This generates smaller and faster code.
Before (using go stdlib)
After (using new js native)
I also wrote a small Itoa benchmark since there wasn't one in std lib. This uses 123456789 as the test number