Overview - Router

router

7 days30 days

Latest CI Pipeline Executions

Fuzzy

Succeeded
main
ba52d2b8 perf(start-client-core): zero-copy frame payload extraction (#7662) extractFlattened() always allocated a new Uint8Array and copied `count` bytes, even when the requested bytes were fully contained in the first buffered chunk (the common case, since most frames arrive within a single network read). Add a fast path that returns a subarray view of the first chunk when the bytes are contiguous, avoiding the allocation and the byte copy. The multi-chunk path is unchanged. The returned view shares the chunk's backing ArrayBuffer, which is safe because buffered chunks are never mutated in place after being read. This is on the hot path for decoding every streamed server-function response and RawStream binary payload on the client. A micro-benchmark shows ~3x faster extraction for 1KB frames and ~27x for 64KB frames (the win scales with payload size).
by Yagiz Nizipli
Failed
7665
Environment issue→
b4a33036 perf(router-core): guard default search parser against throws defaultParseSearch ran JSON.parse on every leftover string search value. For plain strings (the common case, e.g. ?q=hello&f=live) JSON.parse throws a SyntaxError that parseSearchWith catches to keep the raw string — and constructing/throwing that error is the dominant cost. Add a couldBeJson guard that decides from the first non-whitespace character whether a value could be valid JSON. It is a superset of JSON's value-start grammar, so any string JSON.parse would accept still gets parsed (identical results); we only skip the guaranteed-throwing parse of non-JSON strings. Search params are parsed on every SSR request and every client navigation. In-situ before/after on defaultParseSearch: ~3.1x faster on mixed X-like queries, ~1.7x on an all-plain-string query.
by Yagiz Nizipli
Succeeded
7663
38c9d48a perf(start-client-core): O(1) buffer drain in client frame decoder The frame decoder dropped consumed chunks from its buffer with bufferList.shift(), which is O(n). When a single large frame (e.g. a big RawStream payload) is assembled from many small network reads, the extract loop calls shift() once per chunk, making reassembly O(n^2). Track the first un-consumed chunk with a head pointer and advance it in O(1) instead of shifting. Consumed slots are released for GC, and the buffer is compacted when fully drained (O(1) reset) or once the consumed prefix grows past a small threshold (amortized O(1) per chunk). A micro-benchmark draining 1000 small chunks is ~11x faster.
by Yagiz Nizipli
Succeeded
7662
309f3d37 perf(start-client-core): zero-copy frame payload extraction extractFlattened() always allocated a new Uint8Array and copied `count` bytes, even when the requested bytes were fully contained in the first buffered chunk (the common case, since most frames arrive within a single network read). Add a fast path that returns a subarray view of the first chunk when the bytes are contiguous, avoiding the allocation and the byte copy. The multi-chunk path is unchanged. The returned view shares the chunk's backing ArrayBuffer, which is safe because buffered chunks are never mutated in place after being read. This is on the hot path for decoding every streamed server-function response and RawStream binary payload on the client. A micro-benchmark shows ~3x faster extraction for 1KB frames and ~27x for 64KB frames (the win scales with payload size).
by Yagiz Nizipli
Succeeded
7664
d18d300d perf(router-core): faster enumerable-key collection in structural sharing getEnumerableOwnKeys (used by replaceEqualDeep) called Object.getOwnPropertyNames and then invoked propertyIsEnumerable once per key to verify every own string prop is enumerable. Replace that O(n) loop of JS method calls with Object.keys (native, enumerable-only) plus a single length comparison against getOwnPropertyNames to detect non-enumerable string props. Symbol handling is unchanged. Behavior is identical (verified against the existing suite + fuzzing): the function still returns the enumerable own keys in the same order and still bails (returns false) for objects with any non-enumerable own string or symbol property. replaceEqualDeep runs on every selector result on every state update when defaultStructuralSharing is enabled, so this is a hot client path for selector-heavy apps. Measured ~1.3-1.5x faster on typical router state.
by Yagiz Nizipli