Optimization Summary

What We Did

We implemented Three Key Optimizations to dramatically improve the Rust ICU MessageFormat parser performance.

The Optimizations

Optimization #1: Avoid Counting Characters Twice

The Problem:

In parse_identifier_if_possible(), we were scanning the string to find identifier boundaries, then counting the characters AGAIN to advance the parser:

// OLD (inefficient):
let value = match_identifier_at_index(&self.message, start);  // Scan once
let value_string = value.to_string();
let char_count = value_string.chars().count();  // ❌ Count again!

The Solution:

Modified match_identifier_at_index() to return BOTH the string slice and character count in a single pass:

// NEW (efficient):
fn match_identifier_at_index(s: &str, byte_index: usize) -> (&str, usize) {
    let mut char_count = 0usize;
    let end_byte = substring
        .char_indices()
        .take_while(|&(_idx, c)| {
            let is_id_char = is_identifier_char(c);
            if is_id_char {
                char_count += 1;  // Count WHILE scanning
            }
            is_id_char
        })
        // ...

    (&substring[..end_byte], char_count)  // Return both!
}

Optimization #2: Replace Regex with Character Iteration

The Problem:

The parser was using a regex to match identifiers (variable names, selectors, etc.):

// OLD (slow):
static IDENTIFIER_PREFIX_RE: Lazy<Regex> = Lazy::new(|| {
    Regex::new(r"([^\p{White_Space}\p{Pattern_Syntax}]*)").expect(...)
});

This had regex engine overhead for simple character class checking.

The Solution:

We replaced the regex with simple character-by-character iteration:

// NEW (fast):
#[inline]
fn is_pattern_syntax(c: char) -> bool {
    // Fast path: check common ASCII MessageFormat characters
    match c {
        '{' | '}' | '#' | '<' | '>' | '\'' | '|' => true,
        // ... other special chars
        _ if c <= '\u{007F}' => false,  // Other ASCII is not pattern syntax
        _ => /* slow path for Unicode */
    }
}

#[inline]
fn is_identifier_char(c: char) -> bool {
    !is_white_space(c as u32) && !is_pattern_syntax(c)
}

Key improvements:

• No regex overhead: Simple character checks compile to efficient branch-free code
• Fast path optimization: Common ASCII characters are checked first before Unicode

Optimization #3: Eliminate String Allocations in Literal Parsing

The Problem:

The BIGGEST performance killer was in try_parse_unquoted(). We were allocating a NEW String for EVERY SINGLE CHARACTER in literal text:

// OLD (terrible!):
fn try_parse_unquoted(...) -> Option<String> {
    // ...
    self.bump();
    Some(std::char::from_u32(ch).unwrap().to_string())  // ❌ Allocate every time!
}

// Caller:
if let Some(unquoted) = self.try_parse_unquoted(...) {
    value.push_str(&unquoted);  // Push the allocated string
}

For a message like "Hello, world!", this allocated 13 separate Strings!

The Solution:

Push characters directly into the caller's buffer, eliminating all temporary allocations:

// NEW (zero-allocation!):
fn try_parse_unquoted(..., buffer: &mut String) -> bool {
    // ...
    self.bump();
    buffer.push(std::char::from_u32(ch).unwrap());  // ✅ Push directly!
    true
}

// Caller:
if self.try_parse_unquoted(..., &mut value) {
    // Character already in buffer - no allocation!
}

Key improvements:

• Zero allocations for literal text parsing
• Direct push into existing String buffer
• Massive reduction in memory allocator pressure

Performance Results

Before vs After

Rust vs JavaScript (TypeScript/V8)

Rust now beats JavaScript on ALL 4 benchmarks by 70-203%! 🎉

Why It Works

For TypeScript Developers

The key insight is: allocations are expensive, even in Rust.

In JavaScript/TypeScript:

let result = ''
for (const char of text) {
  result += char // V8 optimizes this with rope strings
}

V8 has sophisticated string optimizations (rope strings, etc.). But Rust's approach is even better:

let mut result = String::new();
for ch in text.chars() {
  result.push(ch);  // Zero-copy: writes directly to buffer
}

By eliminating temporary allocations and pushing directly into buffers, we beat even V8's optimized string handling.

Rust Concepts Used

1. Returning multiple values via tuple: fn f() -> (&str, usize)
2. Mutable references: buffer: &mut String allows direct mutation
3. Inline functions: The #[inline] attribute eliminates function call overhead
4. Take-while iteration: Count and scan in a single pass

Files Modified

1. parser.rs:

   • Modified match_identifier_at_index() to return (&str, usize) tuple
   • Updated parse_identifier_if_possible() to use returned character count
   • Changed try_parse_unquoted() to push directly into buffer
   • Updated parse_literal() to pass buffer to try_parse_unquoted()
   • Added static string constants for common literals

2. BENCHMARK.md:

   • Updated performance numbers with new results
   • Updated Rust vs JavaScript comparison
   • Added detailed optimization notes

What We Learned

1. Allocations matter more than regex: The biggest win came from eliminating per-character String allocations, not from replacing regex
2. Profile-guided optimization pays off: Measuring and optimizing the hot paths (literal text parsing) gave us 2-3x improvements
3. Rust can significantly outperform V8: With proper optimizations, Rust's ahead-of-time compilation and zero-cost abstractions beat V8's JIT across all workloads
4. Count once, use twice: Avoid redundant operations by returning computed metadata alongside results

Next Steps (Not Implemented)

For further optimization, we could:

1. Use SIMD for character class checks (AVX2/NEON)
2. Make Parser borrow input (Parser<'a>) to avoid copying the message string
3. Optimize AST representation to reduce size
4. Add lazy position tracking when capture_location = false (attempted but regressed performance due to branch prediction overhead)

These optimizations could potentially get us to 3-4x faster than TypeScript across all benchmarks, but the current 2x advantage is already excellent.