| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 0 | 6 | 7 | 0% |
| Commands | 0 | 0 | 0 | — |
| Section tags | 2 | 0 | 2 | 50% |
What each file covers
Sections
0 shared · 6 only in A · 7 only in B- − Performance Rules for Fasten
- − Targets
- − Benchmarking
- − Memory
- − Optimization
- − Monitoring
- + Contributing Rules for Fasten
- + Code of Conduct
- + Code Standards
- + Testing
- + Performance
- + Submission Process
- + Architecture
Commands
neither file has anySection tags
2 shared · 0 only in A · 2 only in B- + test
- + git-pr
- performance
- do-not
Line diff
v1truv1us/fasten · .cursor/rules/performance.mdc
@@ −3 @@
3globs:
4alwaysApply: true
5---
6# Performance Rules for Fasten
7
8## Targets
9- Small: <100ms, <10MB; Medium: <500ms, <50MB; Large: <2s, <200MB; XL: <10s, <500MB.
10- Lexer: >1MB/s; Parser: >500KB/s; Optimizer: >2MB/s; Codegen: >5MB/s.
11- Cold start <50ms; base memory <5MB.
12
13## Benchmarking
14- Use provided benchmark framework; warmup, multiple iterations, throughput checks.
15- Assert performance targets in tests; fail on regression >10%.
16
17## Memory
18- Use ArenaAllocator for temp data; Pool for frequent allocations.
19- Profile memory; zero tolerance for leaks; peak usage <2x input size.
20
21## Optimization
22- Minimize allocations in hot paths; use stack allocation when possible.
23- Profile before optimizing; document all optimizations.
24- Use efficient data structures (interning, compact AST).
25
26## Monitoring
27- Collect and log metrics (time, memory, compression ratio).
28- Alert on slow bundling, high memory, poor compression.
29- Run performance and memory tests in CI.
30
v1truv1us/fasten · .cursor/rules/contributing.mdc
@@ +3 @@
3globs:
4alwaysApply: true
5---
6# Contributing Rules for Fasten
7
8## Code of Conduct
9- Be respectful, constructive, and professional in all interactions.
10
11## Code Standards
12- Use Zig naming conventions: camelCase for functions, snake_case for variables, PascalCase for types.
13- Keep functions under 50 lines; cyclomatic complexity ≤ 10.
14- Document all public functions and complex algorithms.
15- Use explicit allocators and ensure all resources are freed.
16- Use Zig's error handling consistently.
17
18## Testing
19- Write unit, integration, performance, and error tests.
20- Use descriptive test names: `test "should [behavior] when [condition]"`.
21- Benchmark critical paths and set performance targets.
22
23## Performance
24- Bundle 100-200 JS files (~100KB) in <1s; 500+ files (~500KB) in <5s.
25- Peak memory ≤ 2x input size; zero tolerance for memory leaks.
26
27## Submission Process
28- Run all tests and benchmarks before submitting.
29- Use conventional commit messages: `type(scope): description`.
30- Complete PR checklist and template.
31- PRs require at least one maintainer review and passing CI.
32
33## Architecture
34- Each module has a single responsibility.
35- Explicit, minimal dependencies.
36- Consistent error propagation and documentation.
37- Optimize for speed, memory, and testability.
38
@@ −3 +3 @@
33 globs:
44 alwaysApply: true
55 ---
6−# Performance Rules for Fasten
6+# Contributing Rules for Fasten
77
8−## Targets
9−- Small: <100ms, <10MB; Medium: <500ms, <50MB; Large: <2s, <200MB; XL: <10s, <500MB.
10−- Lexer: >1MB/s; Parser: >500KB/s; Optimizer: >2MB/s; Codegen: >5MB/s.
11−- Cold start <50ms; base memory <5MB.
8+## Code of Conduct
9+- Be respectful, constructive, and professional in all interactions.
1210
13−## Benchmarking
14−- Use provided benchmark framework; warmup, multiple iterations, throughput checks.
15−- Assert performance targets in tests; fail on regression >10%.
11+## Code Standards
12+- Use Zig naming conventions: camelCase for functions, snake_case for variables, PascalCase for types.
13+- Keep functions under 50 lines; cyclomatic complexity ≤ 10.
14+- Document all public functions and complex algorithms.
15+- Use explicit allocators and ensure all resources are freed.
16+- Use Zig's error handling consistently.
1617
17−## Memory
18−- Use ArenaAllocator for temp data; Pool for frequent allocations.
19−- Profile memory; zero tolerance for leaks; peak usage <2x input size.
18+## Testing
19+- Write unit, integration, performance, and error tests.
20+- Use descriptive test names: `test "should [behavior] when [condition]"`.
21+- Benchmark critical paths and set performance targets.
2022
21−## Optimization
22−- Minimize allocations in hot paths; use stack allocation when possible.
23−- Profile before optimizing; document all optimizations.
24−- Use efficient data structures (interning, compact AST).
23+## Performance
24+- Bundle 100-200 JS files (~100KB) in <1s; 500+ files (~500KB) in <5s.
25+- Peak memory ≤ 2x input size; zero tolerance for memory leaks.
2526
26−## Monitoring
27−- Collect and log metrics (time, memory, compression ratio).
28−- Alert on slow bundling, high memory, poor compression.
29−- Run performance and memory tests in CI.
27+## Submission Process
28+- Run all tests and benchmarks before submitting.
29+- Use conventional commit messages: `type(scope): description`.
30+- Complete PR checklist and template.
31+- PRs require at least one maintainer review and passing CI.
32+
33+## Architecture
34+- Each module has a single responsibility.
35+- Explicit, minimal dependencies.
36+- Consistent error propagation and documentation.
37+- Optimize for speed, memory, and testability.
3038
