Skip to content

Add mojo-optimizations skill#8

Open
msaelices wants to merge 5 commits intomodular:mainfrom
msaelices:mojo-optimizations-skill
Open

Add mojo-optimizations skill#8
msaelices wants to merge 5 commits intomodular:mainfrom
msaelices:mojo-optimizations-skill

Conversation

@msaelices
Copy link
Copy Markdown

@msaelices msaelices commented Apr 11, 2026

Summary

  • New mojo-optimizations skill capturing performance optimization patterns for Mojo. Layers on top of mojo-syntax and is triggered when profiling, benchmarking, tuning latency, or porting performance-sensitive code to Mojo.
  • Covers hot-path inlining, unsafe pointer access in inner loops, pre-allocation and lazy containers, struct layout for cache efficiency, views over owned strings, ref over var in loops, _Global lazy caches, init_pointee_move for heap fields, hash-keyed caching, comptime specialization, nibble-based SIMD byte scanning, prefiltering strategies, numeric accumulation, fast-path dispatch by input shape, and guidance on what not to optimize.
  • Follows the existing skill style (terse, table/WRONG-CORRECT-heavy, editorial-guidelines comment block) and updates the top-level README.md with an entry for the new skill.

New skill capturing performance optimization patterns for Mojo code. Layers
on top of mojo-syntax and is triggered when profiling, benchmarking, tuning
latency, or porting performance-sensitive code to Mojo. Covers hot-path
inlining, unsafe pointer access in inner loops, pre-allocation and lazy
containers, struct layout for cache efficiency, views over owned strings,
ref over var in loops, _Global lazy caches, init_pointee_move for heap
fields, hash-keyed caching, comptime specialization, nibble-based SIMD byte
scanning, prefiltering strategies, numeric accumulation, fast-path dispatch
by input shape, and guidance on what not to optimize.
@msaelices msaelices changed the title [Skills] Add mojo-optimizations skill Add mojo-optimizations skill Apr 11, 2026
@msaelices msaelices marked this pull request as draft April 11, 2026 22:27
Replace the hand-rolled perf_counter_ns harness with the stdlib
std.benchmark idiom (Bench, Bencher, BenchConfig, BenchId, keep,
ThroughputMeasure). Matches the pattern used in mojo/stdlib/benchmarks/
so users copy-paste from the reference tree instead of reinventing
warmup and calibration logic.
…ehavior

The previous text incorrectly claimed List, Span, and StringSlice all
emit a bounds check on every __getitem__ call. Verified against the
stdlib (std/collections/_index_normalization.mojo and
std/builtin/debug_assert.mojo): List and Span both pass
assert_always=False to normalize_index, so their bounds check compiles
out in default (ASSERT=safe) release builds. Only StringSlice[byte=i]
emits the check by default, plus a UTF-8 start-byte debug_assert.

Replace the section with a per-type table of actual costs, explain what
unsafe_ptr() reliably buys you in default release (negative-index
branch, trap-free loop optimization, parity with -D ASSERT=all builds),
and mention list.unsafe_get(idx) as a safer middle ground.
Replace the regex-specific example (CompiledRegex, _get_regex_cache,
ImmSlice) with a neutral get_or_build pattern that applies to any
expensive value keyed by a string. Add a brief list of use cases
(parsed configs, compiled templates, resolved paths, interned symbols,
SQL plans) so readers see the shape beyond regex.
Replace regex-flavored examples (CompiledRegex, DFAMatcher, Match,
LazyDFA, compile_regex, match_first, is_match, .*literal) with a
variety of neutral domains:
- Benchmark: parse_json
- Inlining trampolines: JsonParser -> Tokenizer -> ByteScanner
- Struct layout: Token (tokenizer output)
- Views: tokenize(source)
- ref over var: rows, table
- Global caches: SymbolTable, intern()
- init_pointee_move: Arena
- SIMD scanning: JSON whitespace, CSV delimiters, URL-safe chars
- Prefilters: log scanning, filename extraction, JSON value detection
- Fast-path dispatch: QueryPlan (pk lookup, sequential scan, general)
- Unlikely-branch hoisting: validate(input)
@msaelices msaelices marked this pull request as ready for review April 11, 2026 23:01
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