Skip to content

Cut scratch allocation for short compression inputs - #40

Merged
rafambn merged 1 commit into
dev-1.1.0from
agent/deflate-scratch-sizing
Sep 9, 2026
Merged

rafambn merged 1 commit into
dev-1.1.0from
agent/deflate-scratch-sizing

Conversation

@rafambn

@rafambn rafambn commented Sep 9, 2026

Copy link
Copy Markdown
Owner

Short inputs currently allocate a 65,536-entry token array and full history ring. Bound scratch arrays by input length for final calls, while non-final streams retain the full reusable history ring.

A three-fork Linux JVM confirmation measured 6.11x faster compression for the 100-byte fixture, 27.0 to 4.4 microseconds, and 1.30x for the small model. Large fixtures retain their previous allocation sizes; text timings vary across unchanged-baseline forks, so no text-speed claim is made.

Linux tests cover empty/tiny inputs, dictionaries and final/non-final history reuse. All 70 corpus/level outputs passed JDK and KFlate decoding and matched baseline SHA-256 hashes. Full 100% instruction/branch coverage verification passed.

Initial and three-fork confirmation samples, output sizes and saved Kompress comparisons are in performance/2026-09-09-scratch/RESULTS.md. Independent PR against dev-1.1.0.

@rafambn
rafambn merged commit ba01d65 into dev-1.1.0 Sep 9, 2026
3 checks passed
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