Skip to content

Switch gzip compression to klauspost/compress#335

Open
matucker-msft wants to merge 1 commit into
Azure:masterfrom
matucker-msft:klauspost-gzip
Open

Switch gzip compression to klauspost/compress#335
matucker-msft wants to merge 1 commit into
Azure:masterfrom
matucker-msft:klauspost-gzip

Conversation

@matucker-msft

Copy link
Copy Markdown
Member

Changed

Replace compress/gzip with github.com/klauspost/compress/gzip (v1.18.5) for upload compression in the ingest pipeline.

Why

klauspost/compress is an optimized, drop-in replacement for the standard library's compress/gzip package that provides:

  • ~2x faster compression compared to stdlib at equivalent compression levels, thanks to hand-tuned assembly (x86) and optimized pure-Go fallbacks
  • Drop-in API compatibility — same interface as compress/gzip, no code changes needed beyond the import path
  • Widely adopted — used by 263k+ repositories including major projects across the Go ecosystem (5.5k GitHub stars, 72 contributors)
  • Actively maintained — regular releases with ongoing performance improvements and security fixes (111 releases, latest v1.18.5)
  • Same license as the Go standard library (BSD-style)

For ingestion workloads that compress data before uploading to Kusto, the improved compression throughput reduces CPU time and lowers end-to-end ingest latency.

This was previously raised in #205, and closed because "we rather not include extra deps unless it's critical." I am re-opening as a sign that this is critical and drastically improves compression time and cpu utilization.

@matucker-msft

matucker-msft commented Apr 1, 2026

Copy link
Copy Markdown
Member Author

Just here to say I am definitely a human. Feel free to reach out on teams with any concerns (or here in github if you want to keep it public, I dont care!). I understand the concerns of adding a dependency, but I also understand the concerns of gzip compression taking more time and cpu. We get value out of swapping this out and have been maintaining a fork since Jason originally opened his PR. I dont like maintaining forks, so I am here again :)

@MaurGi

MaurGi commented Apr 1, 2026

Copy link
Copy Markdown
Member

Hello - we would prefer not having to fork please - we have been using this library for a while ant it is superior in performance - thank you!

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.

2 participants