The Wire · Showcase
Elixir trims trailing whitespace with zero-cost slicing
By RepoJournal · Filed · About Elixir & Phoenix
Elixir's trim_trailing/1 just got a whole lot cheaper, and it's not the only performance fix in the pipeline.
A new PR [1] from Daniel Kukula reworks String.trim_trailing/1 to avoid per-step slicing allocations, so the common case of one-byte whitespace now needs no lookahead. The follow-up notes that the approach starts to lose its edge only around 1k trailing characters [2], making it a clear win for typical strings. Meanwhile, another fix addresses a base64 SWAR singleton false positive [3], closing an edge case in the SIMD-like validation. In the Ecto world, a PR [4] sorts escaped map/struct fields to guarantee deterministic compile output, fixing builds that could produce different bytecode from the same source across compiler invocations. These are quiet, surgical improvements, but they add up to a more predictable and faster Elixir toolchain.
One email a day. Unsubscribe in one click.
Keep up with Elixir & Phoenix in about 3 minutes a day: what actually shipped — the commits, pull requests, releases, and security advisories that matter.
One email a day. Unsubscribe in one click. Read a past issue →
Action items
- → Review PR #15780 for trim_trailing/1 and test against your hot string paths elixir-lang/elixir [plan]
- → Monitor PR #15773 for base64 SWAR fix and the Ecto deterministic compile output PR elixir-ecto/ecto [monitor]
References
- [1] Trim trailing whitespace without slicing per step (#15780) elixir-lang/elixir
- [2] Trim trailing whitespace without slicing per step ↗ elixir-lang/elixir
- [3] Fix base64 swar singleton false positive ↗ elixir-lang/elixir
- [4] Sort escaped map/struct fields for deterministic compile output ↗ elixir-ecto/ecto