Open 177d8476-2756-4152-91d7-984f74d3896c opened 6 years ago
A re-written implementation that is less overly generic, thereby permitting inlining without seriously increasing code size, has been merged in PR #36623. Performance on microbenchmarks is improved up to 50%.
Further optimizations for bit width ≤ 64 and/or for common bases may be possible.
Additional Detail from JIRA
| | | |------------------|-----------------| |Votes | 0 | |Component/s | Standard Library | |Labels | Bug | |Assignee | None | |Priority | Medium | md5: 6c726c2bcb53150bc4c96ab17a6f1588relates to:
Issue Description:
Constructing an Int from a String eventually involves calling
parseASCII
, which is slow and bloated if not properly specialized. A serious of unfortunate events played out over time where this function was overly generic and so was markedinline(__always)
to be fast, then it was discovered this function was about 20KB large and the callers were all marked with@inline(never)
and various@semantics
to disable specialization for size (and perhaps compilation time). The end result was something bloated, slow, and yet is still emitted into the user module, increasing code size.However, a simpler and more efficient implementation should be easily implementable. At the very least, it could hard code fast-paths for radices of 10 or 16, and fall back to slow paths for the rest.