Skip to content

repr: fast-path timestamp/date/time parsing#35161

Draft
def- wants to merge 3 commits intoMaterializeInc:mainfrom
def-:pr-repr-timestamp
Draft

repr: fast-path timestamp/date/time parsing#35161
def- wants to merge 3 commits intoMaterializeInc:mainfrom
def-:pr-repr-timestamp

Conversation

@def-
Copy link
Contributor

@def- def- commented Feb 22, 2026

Taken and cleaned up from #35076

@github-actions
Copy link

Thanks for opening this PR! Here are a few tips to help make the review process smooth for everyone.

PR title guidelines

  • Use imperative mood: "Fix X" not "Fixed X" or "Fixes X"
  • Be specific: "Fix panic in catalog sync when controller restarts" not "Fix bug" or "Update catalog code"
  • Prefix with area if helpful: compute: , storage: , adapter: , sql:

Pre-merge checklist

  • The PR title is descriptive and will make sense in the git log.
  • This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
  • If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post.
  • This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
  • If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
  • If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).

@def- def- force-pushed the pr-repr-timestamp branch from a55d279 to 993ab7e Compare February 22, 2026 23:01
@def- def- changed the title repr: fast-path ISO 8601 timestamp/date/time parsing - 15-22x speedup repr: fast-path timestamp/date/time parsing Feb 22, 2026
@def- def- force-pushed the pr-repr-timestamp branch 3 times, most recently from 338a3f3 to d716cb3 Compare February 23, 2026 11:21
def- and others added 2 commits February 23, 2026 13:02
Add direct byte-level ISO 8601 parsers that bypass the general-purpose
ParsedDateTime tokenizer+pattern-matcher for standard format inputs.
The fast path eliminates VecDeque heap allocation, character-by-character
tokenization, token pattern matching, and 264-byte ParsedDateTime struct
initialization, replacing it all with 7 byte comparisons + 6 two-digit
parses + chrono construction (~25ns total vs ~350ns).

Benchmark results (per-value):
- Timestamp: 319ns → 14ns (22x faster)
- Timestamptz: 413ns → 23ns (18x faster)
- Date: 191ns → 10ns (19x faster)
- Time: 152ns → 8ns (20x faster)

Batch 10k values:
- Timestamps: 3.55ms → 198µs (18x faster)
- Timestamptz: 4.42ms → 257µs (17x faster)
- Dates: 2.06ms → 122µs (17x faster)
- Times: 1.89ms → 126µs (15x faster)

Non-standard formats fall back to the general parser with <1ns overhead.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…utput

Replace chrono's `ts.format("%m-%d %H:%M:%S")` with direct field extraction
and stack-buffer byte writing in all four date/time formatting functions:
format_timestamp, format_timestamptz, format_date, and format_time.

The old code parsed the format string on every call, creating a DelayedFormat
struct and iterating through format directives. The new code extracts fields
directly (month(), day(), hour(), etc.) and writes them via simple arithmetic
into a stack-allocated byte buffer, emitting the result with a single
write_str() call.

Also optimizes format_nanos_to_micros to build ".NNNNNN" in a stack buffer
and trim trailing zeros, avoiding write! with dynamic width.

Benchmarks (criterion, cargo bench -p mz-repr --bench timestamp_format):
- Per-value: 10-22x faster (e.g. timestamp: 160ns → 8.5ns)
- Batch 10k timestamps: 1,680µs → 115µs (14.6x faster)
- Batch 10k timestamptz: 1,790µs → 141µs (12.7x faster)

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@def- def- force-pushed the pr-repr-timestamp branch from d716cb3 to ba92461 Compare February 23, 2026 13:02
@def- def- force-pushed the pr-repr-timestamp branch from ba92461 to b6c97fe Compare February 23, 2026 17:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant