Optimize lstripChars, rstripChars, and stripChars via specialization #236
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR optimizes
lstripChars
/rstripChars
/stripChars
built-in functions by using the specialization framework from #119 / 0bd255a to pre-compile and re-usePattern
instances when the replacement / strip arguments are constants.In Java,
String.replaceAll()
compiles and uses aPattern
under the hood and this is relatively expensive; specialization lets us save this cost when thechars
-to-be-stripped are constant.Testing
Correctness: ran all tests with a manual change to disable static function application optimizations (a prerequisite required to achieve full test coverage, as the static application prevents specialization from kicking in during most tests). In a followup, I think we should explore adding flags for optimizer features and running all tests with/without optimization.
Performance: ran benchmarks on a large file and with this change I save ~11% of allocated bytes and ~8% of wall time. I ran that same file through
RunProfiler
and saw a large speedup instripChars
, costing ~619ns/call before and ~154ns/call after.