The GitHub Actions job "Scalafmt" on pekko.git/bytestring-equals-perf has failed. Run started by GitHub user pjfanning (triggered by pjfanning).
Head commit for run: 58f0a72ba4c6df0409b92c33b3eaa080d938554a / PJ Fanning <[email protected]> perf: memoise the fragment lookup in ByteStrings `ByteStrings.apply` resolved an index by scanning the fragment vector from the start on every call, and `byteAtUnchecked` was not overridden at all, so it fell back to `apply`. Any operation that walks a fragmented ByteString by index was therefore quadratic in the number of fragments: traversing a 1024-fragment ByteString took around 410ms, against 3ms once the lookup is memoised. `byteAtUnchecked` now remembers the fragment resolved by the previous call. Sequential access -- the dominant pattern -- either stays inside that fragment or resumes the scan from it. `apply` becomes a bounds check in front of `byteAtUnchecked`, so both share the memoised lookup and the duplicated scan is gone. The remembered triple is held in a single immutable object and published by one reference write. Readers take a single reference and can never observe the start of one fragment paired with the index of another, which three separate int fields would allow. The field is deliberately not volatile: it is only a hint, so a reader that misses another thread's update simply rescans, and ByteString is immutable, so a resolved mapping never becomes wrong. This also speeds up the artery TCP framing path: `ByteStringParser`'s `ByteReader` reads sequentially with `apply`, and the `read*Unchecked` helpers that `ByteStrings` does not override are built from `apply`. Tests cover forward, backward, repeated and alternating access, the agreement with `toArray` and the iterator, out of range indices, and concurrent reads from several threads. Report URL: https://github.com/apache/pekko/actions/runs/32737247232 With regards, GitHub Actions via GitBox --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
