[moberegger]

Saw this coming up as a hotspot in our production profiles.

Found a few optimization candidates that looked lower risk to implement:

• Used encoded.to_i instead of encoded[0, s1 + 1].to_i. String#to_i will stop parsing at the first non-numeric character, so calling it on the full string yields the same result as extracting a substring first. This eliminates a string allocation.
• Use byteindex instead of index. Since the pipe delimiter | is a single-byte ASCII character, this produces the same result but skips character-encoding boundary checks (At least that is my undertanding). (Note: I believe Ruby 3.2+ is required for byteindex, but this is specified is the minimum Ruby version in the gemspec.)
• Used byteslice instead of []. If the encoded format is always ASCII-safe, byteslice can skip the character-encoding boundary checks that String#[] performs. This is a cheaper operation for the same result.
• Used encoded.bytesize instead of encoded.size. This avoids a character-length scan on the string.
• Added an include? guard before gsub!. Saves on a gsub! in situations where there is nothing to substitute. I am not sure how common the $$123$$ escape sequence will be present, but this will skip that overhead when it's not necessary.

Benchmarks against Messagebus::Message.decode

Encoded payload: 12345|678|/test/channel|{"hello":"world","nums":[1,2,3]}

=== Memory allocation ===
Calculating -------------------------------------
            original   400.000  memsize (     0.000  retained)
                         6.000  objects (     0.000  retained)
                         5.000  strings (     0.000  retained)
           optimized   360.000  memsize (     0.000  retained)
                         5.000  objects (     0.000  retained)
                         4.000  strings (     0.000  retained)

Comparison:
           optimized:        360 allocated
            original:        400 allocated - 1.11x more

=== Iterations per second ===
ruby 4.0.2 (2026-03-17 revision d3da9fec82) +YJIT +PRISM [arm64-darwin25]
Warming up --------------------------------------
            original   192.230k i/100ms
           optimized   264.842k i/100ms
Calculating -------------------------------------
            original      2.007M (± 5.2%) i/s  (498.26 ns/i) -     10.188M in   5.093215s
           optimized      2.862M (± 2.7%) i/s  (349.45 ns/i) -     14.566M in   5.094083s

Comparison:
            original:  2006971.2 i/s
           optimized:  2861611.7 i/s - 1.43x  faster

[Copilot]

🔵 Needs a closer look

Byte-oriented parsing lacks requested multibyte channel test coverage.

Pull request overview

Optimizes MessageBus::Message.decode using byte-oriented operations and fewer allocations.

Changes:

• Replaces character-based indexing and slicing with byte-based equivalents.
• Avoids unnecessary substring allocation and substitution work.
• Requests multibyte channel round-trip coverage.

File summaries

File	Description
lib/message_bus/message.rb	Optimizes message decoding while preserving behavior.

Review details

Suppressed comments (1)

lib/message_bus/message.rb:10

• The byte-based parsing path is only directly covered by an ASCII round-trip (backend_spec.rb:83-85). Please add a round-trip case with a multibyte channel (ideally also containing |) so the byte offsets and byteslice boundaries are protected against encoding regressions.

    s1 = encoded.byteindex("|")
    s2 = encoded.byteindex("|", s1 + 1)
    s3 = encoded.byteindex("|", s2 + 1)

• Files reviewed: 1/1 changed files
• Comments generated: 0
• Review effort level: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[moberegger]

The byte-based parsing path is only directly covered by an ASCII round-trip (backend_spec.rb:83-85). Please add a round-trip case with a multibyte channel (ideally also containing |) so the byte offsets and byteslice boundaries are protected against encoding regressions.

I can take a closer look at this. Looks like it might just be some additional test coverage? Wouldn't hurt to do the extra due diligence (... and I suppose there might be some nuance here that I am missing).

[moberegger]

@SamSaffron Added some extra tests, including one for multi-byte channels.