oxc-project/oxc - CodSpeed

oxc

Instrumentation

Wall Time

Blog Docs Changelog

Performance History

Latest Results

[autofix.ci] apply automated fixes

nnnnoel:fix/ts-type-operator

10 minutes ago

fix(formatter): keep computed name in enum (#13848)

main

12 minutes ago

docs(parser): document is_on_new_line and read_bool performance characteristics (#13867) ## Summary This PR adds comprehensive documentation to the `is_on_new_line` and `read_bool` methods in the lexer's Token implementation, based on the performance analysis from PR #13788. ## Changes - Document `is_on_new_line`'s purpose for ASI and JavaScript parsing rules - Add detailed performance analysis to `read_bool` showing assembly code comparison - Explain why unsafe pointer arithmetic is used (3 instructions vs 4 for bit operations) - Reference PR #13788's benchmarking discussion for historical context ## Context As discussed in #13788, the unsafe pointer arithmetic implementation was retained because it generates one fewer CPU instruction on this hot path. This documentation helps future contributors understand this design decision. ### Assembly Comparison **Unsafe pointer arithmetic (current):** ```asm movzx eax, BYTE PTR [rdi+9] ; 3 instructions total and eax, 1 ret ``` **Safe bit operations (proposed but rejected):** ```asm mov rax, QWORD PTR [rdi+8] ; 4 instructions total shr rax, 8 and eax, 1 ret ``` 🤖 Generated with [Claude Code](https://claude.ai/code)

main

18 minutes ago

docs(parser): document is_on_new_line and read_bool performance characteristics (#13867) ## Summary This PR adds comprehensive documentation to the `is_on_new_line` and `read_bool` methods in the lexer's Token implementation, based on the performance analysis from PR #13788. ## Changes - Document `is_on_new_line`'s purpose for ASI and JavaScript parsing rules - Add detailed performance analysis to `read_bool` showing assembly code comparison - Explain why unsafe pointer arithmetic is used (3 instructions vs 4 for bit operations) - Reference PR #13788's benchmarking discussion for historical context ## Context As discussed in #13788, the unsafe pointer arithmetic implementation was retained because it generates one fewer CPU instruction on this hot path. This documentation helps future contributors understand this design decision. ### Assembly Comparison **Unsafe pointer arithmetic (current):** ```asm movzx eax, BYTE PTR [rdi+9] ; 3 instructions total and eax, 1 ret ``` **Safe bit operations (proposed but rejected):** ```asm mov rax, QWORD PTR [rdi+8] ; 4 instructions total shr rax, 8 and eax, 1 ret ``` 🤖 Generated with [Claude Code](https://claude.ai/code)

docs/token-is-on-new-line

22 minutes ago

docs(parser): document is_on_new_line and read_bool performance characteristics Add comprehensive documentation explaining: - Purpose of is_on_new_line for ASI and parsing rules - Assembly-level performance analysis showing 3 vs 4 instructions - Why unsafe implementation was retained per PR #13788 discussion 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>

docs/token-is-on-new-line

30 minutes ago

fix(linter): enforce func-names "never" config for recursive functions Previously, the func-names rule was incorrectly allowing named function expressions when they were recursive, even when the config was set to "never". This was a deviation from ESLint's behavior. This change fixes the rule to correctly flag ALL named function expressions when config is "never", including recursive ones. The recursive function exception now only applies to "always" and "as-needed" configs where the name is actually needed. Changes: - Modified the recursive function check to only apply for "always" and "as-needed" configs - When config is "never", all named function expressions are now flagged as errors - Updated test expectations to reflect correct behavior This aligns with ESLint's implementation where "never" means no names are allowed on function expressions, regardless of whether they need the name for recursion. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>

taearls:07-08-refactor_ast_remove_astkind_for_argument_

3 hours ago

[autofix.ci] apply automated fixes

nnnnoel:fix/type-alias-parameter-group

8 hours ago

perf(parser): optimize Token operations for better performance Replace unsafe pointer arithmetic with direct bit operations in Token methods. This eliminates runtime endianness checks and reduces instruction count. Changes: - Boolean getters now use simple bit shifts instead of pointer arithmetic - Setter methods use single combined operations instead of separate clear/set - Token::new_on_new_line() directly constructs with flag set - Add inline(always) hints for hot path methods (start, end, kind) - Remove unused BOOL_MASK constant and read_bool() method These optimizations improve lexer performance by: - Eliminating unsafe code and runtime checks - Reducing instruction count in hot paths - Better compiler optimization opportunities - Simpler, more predictable code patterns 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>

perf/optimize-token-operations

9 hours ago

Active Branches

fix(formatter): Add parentheses for mixed types

last run

10 minutes ago

0%

refactor(linter): Remove AstKind for Argument

last run

3 hours ago

+3%

fix(formatter): type parameter should be grouped inside `TSTypeAliasDeclaration`

last run

8 hours ago

0%

© 2025 CodSpeed Technology

Home Terms Privacy Docs