Historical performance evidence

Performance evidence under review

Historical report: recorded version 0.4.1 · 2026-09-30 UTC. These measurements are retained for inspection, not as a current speed claim or proof of published-version availability. Cold process comparisons and persistent-session measurements describe different execution paths.

Recorded source: 3d3c37b04d842f9e73e8686ed92486890cde4d73 · macos x86_64 · Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz · 5 samples per row. These are generated naming fixtures, not eight independently observed projects.

See the measured comparison Compare all eight cases

Historical checked cohort 8 / 8 measured

Cold CLI 1.31x recorded faster aggregate

Repeated checks 24.80x recorded Assura session vs rerun native LS-Lint CLI

8 generated project shapes Equivalent naming and structure policy

Assura release CLI LS-Lint native CLI

Cold: 5 process-to-process samples. Warm: 5 persistent-session samples, excluding session setup/startup. Installed hook entry is a separate operation.

Performance evidence under review

Historical cold comparisons, not a current speed claim.

Historical report: recorded version 0.4.1 · 2026-09-30 UTC. The recorded speed comparison isolates the policy surface both tools share. Assura-only checks such as file contents, Markdown, references, and agent repair guidance are reported separately.

Option Best at Agent-loop tradeoff

Assura Fast repository-wide structure, content, and policy signals Persistent sessions, bounded output, and repair guidance for early feedback

LS-Lint Fast file and directory naming rules One-shot filesystem checks; no content rules or rule-specific agent repair guidance

Language linters Deep checks inside code for one language or runtime Essential later layer, but not one language-agnostic project signal

Custom scripts and hooks Project-specific checks and delivery gates Performance and output vary; hooks often arrive after a larger batch of work

Only native LS-Lint is included in the numeric benchmark. Other options are shown for workflow context, not as measured speed claims. Installed agent-hook entry is a separate operation.

Quality policy use case

A package contract agents cannot quietly drift from.

A fully featured Assura policy captures the project practices an agent should preserve. LS-Lint covers the naming and cardinality subset; the comparison below shows the remaining gap.

Agentic monorepo policy

One contract for every package.

The package tree is required while apps remain optional. Every workspace that exists receives the same guidance, manifest, naming, size, and directory-health policy.

Quality policy example

Expected shape

Broad defaults, exact project contracts.

Project rootAlways checked

AGENTS.md, README.md, and workspace files required
Selected policy is visible and project-owned
Dot directories and generated output are bounded

packages/*/Every package

AGENTS.md and package.json required
Recursive defaults cover nested source and docs
Line and child-count thresholds stay advisory
Exact declarations refine closed wildcard rules

$workspace and $skill rebase the repeated hierarchy, while ./**/ applies one compact health layer to every authored directory.

Configuration comparison

The extra lines define quality policies LS-Lint cannot express.

55 policy lines Shared filesystem checks plus five project-quality policies.

42 policy lines Closest naming, scope, count, and ignore coverage.

These are intentionally not equivalent-size configs. Assura is larger because it also defines exact project shape, thresholds, content checks, reusable contracts, and repair context.

CapabilityAssuraLS-Lint

File and directory namingRecursive defaults + reusable rulesSupported with cascading scopes

Generated-output ignoresSupportedSupported

Required project shapeIndependent required and optional pathsExact counts; optional peers excluded

Line and aggregate child limitsAdvisory thresholdsPer-selector counts only

Markdown contentRequired skill frontmatterFilename only

Named hierarchy contracts$workspace + $skill with rule metadataCascades or YAML aliases

Agent repair contextSeverity + fix documentNo native rule

The cold benchmark measures only shared naming, ignore, scope, and cardinality work. Assura-only capabilities are shown here as product coverage, not counted as LS-Lint performance work. All 6 red limitations are exercised against the same pinned native LS-Lint 2.3.0 package used by the performance report.

AssuraFull reusable project contract

rules:

# Progressive-disclosure entrypoints.

agent-entrypoint:

max_lines: 160

severity: low

message: See docs/agent-guidance.md.

skill-entrypoint:

max_lines: 500

markdown:

require_frontmatter: true

message: See docs/agent-guidance.md#skills.

# Shared non-blocking directory health.

folder-health:

limit_children: 10

severity: low

message: See docs/structure.md.

# Closed-directory building blocks.

closed-entry:

exists: 0

message: See docs/agent-guidance.md#layout.

closed:

./*/: $closed-entry

./*: $closed-entry

# Repeated directory contracts.

skill:

./: $closed

./{agents,assets,references,scripts}/:

./: exists:0-1

inherit: false

SKILL.md: exists:1 | $skill-entrypoint

workspace:

AGENTS.md: exists:1 | $agent-entrypoint

package.json: exists:1

structure:

# Directories, as shown by an IDE explorer.

.agents/:

./: exists:0-1 | $closed

skills/:

./: exists:0-1

./*/: kebab-case | $skill

./*: $closed-entry

apps/:

./: exists:0-1

./*/: $workspace

packages/:

./: exists:1

./*/: $workspace

# Required root files, alphabetically.

AGENTS.md: exists:1 | $agent-entrypoint

package.json: exists:1

pnpm-{lock,workspace}.yaml: exists:1

README.md: exists:1

turbo.json: exists:1

# Direct root dot directories.

./.*/: kebab-case | exists:0-10

# Defaults inside every directory, including root.

./**/:

./: $folder-health

./*/: kebab-case

.{md,js,jsx,ts,tsx}: max_lines:500 | severity:low

.md: kebab-case | exact:AGENTS | exact:README

.{js,jsx,ts,tsx}: kebab-case

exclude: ["**/{node_modules,.next,.turbo,dist,coverage}/**"]

Beyond naming Project-owned rulesRequired and optional pathsReusable hierarchyAgent repair guidance

Performance regression suite Measured fixtures stay separate from the use case.

These generated projects isolate pruning, matcher scale, and configuration lookup against equivalent LS-Lint work.

Checked files 2 to 1,501 per fixture

Directories 2 to 801 per fixture

Effective rules 1 to 801 per fixture

Timed samples 5 per case

All eight historical cases See what changes and how the speed changes with it.

Historical report: recorded version 0.4.1 · 2026-09-30 UTC. Each row records equivalent naming, scope, count, and ignore work through both cold release-profile CLIs on a generated fixture. Warm timing uses an already running Assura session, excluding setup/startup; neither row is installed-hook timing. Comparison package: @ls-lint/ls-lint@2.3.0.

Test case Difference tested Cold CLI time Measured difference

Small library Rust package

Small startup-sensitive tree 5 checked · 4 dirs · 6 rules

Assura 3.79 ms LS-Lint 4.82 ms

1.27x faster cold 0.16 ms warm · 29.3x faster

Web app Frontend app

Frontend extensions and assets 5 checked · 4 dirs · 7 rules

Assura 4.13 ms LS-Lint 4.69 ms

1.14x faster cold 0.15 ms warm · 30.5x faster

Package monorepo Two packages

Nested package scopes 7 checked · 10 dirs · 10 rules

Assura 4.43 ms LS-Lint 5.40 ms

1.22x faster cold 0.17 ms warm · 31.8x faster

Strict monorepo policy Apps + packages

Broad root and workspace policy 39 checked · 38 dirs · 38 rules

Assura 5.91 ms LS-Lint 9.00 ms

1.52x faster cold 0.44 ms warm · 20.3x faster

Rule-heavy project Many file types

Many extension rules 192 checked · 9 dirs · 38 rules

Assura 5.31 ms LS-Lint 6.92 ms

1.30x faster cold 0.21 ms warm · 33.1x faster

Generated-heavy project Large ignored areas

Large ignored trees 2 checked · 52 dirs · 2 rules

Assura 4.13 ms LS-Lint 10.7 ms

2.60x faster cold 0.10 ms warm · 104.1x faster

Multipart extension scale 1,500 source files

Long multipart filenames 1,501 checked · 2 dirs · 1 rules

Assura 8.25 ms LS-Lint 13.7 ms

1.66x faster cold 0.15 ms warm · 92.2x faster

Configured scope scale 800 package scopes

Many explicit scopes 801 checked · 801 dirs · 801 rules

Assura 40.5 ms LS-Lint 44.8 ms

1.10x faster cold 2.64 ms warm · 17.0x faster

Three diagnostic fixtures Open a case to inspect its generated tree, source policy, and measured scale.

Filesystem pruning

Generated-heavy project

2.60x faster

project/

src / index-file.ts
generated / 384 files ignored
coverage / 384 files ignored
52 directories in fixture

LS-Lint source excerpt; converted Assura policy measured

ignore:
  - .assura/**
  - generated/**
  - coverage/**
ls:
  .dir: kebab-case
  .ts: kebab-case

Checked: 2 files
Ignored: 769 files
Shape: 52 dirs
Policy: 2 rules

Why this case is tracked

Proves large generated and coverage areas are excluded before they turn a small source check into unnecessary filesystem work.

Assura cold: 4.13 ms
LS-Lint cold: 10.7 ms
Assura warm: 0.10 ms

High file count

Multipart extension scale

1.66x faster

project/

src
file-0000 ... file-1499
*.a.b.c.d.e.f.g.h.i.j.k.js
one kebab-case naming policy

LS-Lint source excerpt; converted Assura policy measured

ignore:
  - .assura
ls:
  .a.b.c.d.e.f.g.h.i.j.k.js: kebabcase

Checked: 1,501 files
Ignored: 1 files
Shape: 2 dirs
Policy: 1 rules

Why this case is tracked

Guards the matcher against repeated work when one multipart extension is applied across 1,500 source files.

Assura cold: 8.25 ms
LS-Lint cold: 13.7 ms
Assura warm: 0.15 ms

High configuration count

Configured scope scale

1.10x faster

project/

pkg-0000 ... pkg-0799
file-name.js in every scope
one explicit rule per scope
root directory naming rule

LS-Lint source excerpt; converted Assura policy measured

ignore:
  - .assura
ls:
  .dir: kebab-case
  pkg-0000:
    .js: kebab-case
  # ... 798 equivalent scopes ...
  pkg-0799:
    .js: kebab-case

Checked: 801 files
Ignored: 1 files
Shape: 801 dirs
Policy: 801 rules

Why this case is tracked

Guards config loading and scope lookup when a monorepo declares 800 explicit package policies.

Assura cold: 40.5 ms
LS-Lint cold: 44.8 ms
Assura warm: 2.64 ms

Why latency matters

Parallel waiting adds up. Late refactors cost more.

A check that feels small in one terminal repeats across every agent, worktree, and edit loop. Fast local signals reduce interruption without turning every early warning into a hard gate.

Parallel loops

Keep feedback off the critical path.

When several agents edit at once, repeated startup and full-tree scans compete for CPU, filesystem access, and wall-clock time.

Deterministic first pass

Use rules before another model turn.

Repository policy can answer structural questions locally, reserving agent context and reasoning for work that needs judgment.

Earlier correction

Warn while the patch is still small.

Assura can surface drift during the loop and reserve blocking behavior for rules explicitly configured as commit or CI gates.

This benchmark measures elapsed runtime. CPU utilization, disk I/O, agent memory or token use, and avoided rework are product rationale for keeping checks fast, not measured outcomes in this report.

Benchmark boundary

The historical comparison covers the rules both tools share.

Each cold row runs the same generated project with an LS-Lint policy migrated into Assura. The aggregate uses all eight accepted fixtures shown above.

Included in the cold comparisonNaming · ignores · scopes · cardinality

Both release CLIs run process to process, including startup, config loading, traversal, validation, and exit.

Not counted against LS-LintLine limits · content · references · repair guidance

These Assura-only capabilities have no native LS-Lint equivalent and are measured separately.

Separate warm resultPersistent Assura session

An already running Assura session is compared with rerunning the native LS-Lint CLI. Session setup/startup and installed-hook entry are excluded.

Inspect every test case Read the full report