starred/sharpcompress
1
0
Fork 0
mirror of https://github.com/adamhathcock/sharpcompress.git synced 2026-02-03 21:23:38 +00:00
Code Issues 975 Packages Projects Releases 20 Wiki Activity

[PR #981] [CLOSED] Fix ~7x performance regression in ArchiveFactory.Open() by deferring stream buffering #1397

New Issue
Open
opened 2026-01-29 22:20:22 +00:00 by claunia · 0 comments
claunia commented 2026-01-29 22:20:22 +00:00
Owner
Copy Link

📋 Pull Request Information

Original PR: https://github.com/adamhathcock/sharpcompress/pull/981
Author: @Copilot
Created: 10/27/2025
Status: ❌ Closed

Base: master ← Head: copilot/fix-decompression-performance-issue

📝 Commits (3)

  • 2927290 Initial plan
  • f27ea2d Initial plan for decompression performance fix
  • 3cc4cce Fix decompression performance by delaying stream wrapping

📊 Changes

2 files changed (+5 additions, -4 deletions)

View changed files

📝 src/SharpCompress/Archives/ArchiveFactory.cs (+2 -1)
📝 src/SharpCompress/packages.lock.json (+3 -3)

📄 Description

Opening archives with ArchiveFactory.Open() became ~7x slower after buffering was added to stream wrapping. The buffering was applied before archive format detection, causing repeated buffer invalidations during the IsArchive() probe sequence as each factory seeks through the stream.

Changes

  • Defer stream wrapping: Move SharpCompressStream buffering to occur after FindFactory() completes format detection
  • Factory detection now operates on unwrapped streams, eliminating buffer thrashing from seek operations
  • Archive reading still benefits from buffering as the wrapped stream is passed to factory.Open()
// Before: buffer applied before detection (slow)
stream = new SharpCompressStream(stream, bufferSize: readerOptions.BufferSize);
return FindFactory<IArchiveFactory>(stream).Open(stream, readerOptions);

// After: buffer applied after detection (fast)
var factory = FindFactory<IArchiveFactory>(stream);
stream = new SharpCompressStream(stream, bufferSize: readerOptions.BufferSize);
return factory.Open(stream, readerOptions);

All 480 tests pass.

Original prompt

This section details on the original issue you should resolve

<issue_title>Decompression performance 7 times slower after updating from 0.31 to 0.32 +</issue_title>
<issue_description>Opening archives with ArchiveFactory.Open() seems to have a significant performance lose (around 7 times slower) after updating from 0.31 to 0.32 + versions.

Anyone noticed any similar behavior? </issue_description>

Comments on the Issue (you are @copilot in this section)

@adamhathcock Any details of what format used?

I want to stick some profiling around the codebase soon</comment_new>

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/adamhathcock/sharpcompress/pull/981 **Author:** [@Copilot](https://github.com/apps/copilot-swe-agent) **Created:** 10/27/2025 **Status:** ❌ Closed **Base:** `master` ← **Head:** `copilot/fix-decompression-performance-issue` --- ### 📝 Commits (3) - [`2927290`](https://github.com/adamhathcock/sharpcompress/commit/292729028b314f045fc718c1fc529122fecc296f) Initial plan - [`f27ea2d`](https://github.com/adamhathcock/sharpcompress/commit/f27ea2d5f6f9b18bf91d2f8a65689589dcfd6a28) Initial plan for decompression performance fix - [`3cc4cce`](https://github.com/adamhathcock/sharpcompress/commit/3cc4ccedfe17b329648a4ecdfde38f9afde197ab) Fix decompression performance by delaying stream wrapping ### 📊 Changes **2 files changed** (+5 additions, -4 deletions) <details> <summary>View changed files</summary> 📝 `src/SharpCompress/Archives/ArchiveFactory.cs` (+2 -1) 📝 `src/SharpCompress/packages.lock.json` (+3 -3) </details> ### 📄 Description Opening archives with `ArchiveFactory.Open()` became ~7x slower after buffering was added to stream wrapping. The buffering was applied before archive format detection, causing repeated buffer invalidations during the `IsArchive()` probe sequence as each factory seeks through the stream. ## Changes - **Defer stream wrapping**: Move `SharpCompressStream` buffering to occur after `FindFactory()` completes format detection - Factory detection now operates on unwrapped streams, eliminating buffer thrashing from seek operations - Archive reading still benefits from buffering as the wrapped stream is passed to `factory.Open()` ```csharp // Before: buffer applied before detection (slow) stream = new SharpCompressStream(stream, bufferSize: readerOptions.BufferSize); return FindFactory<IArchiveFactory>(stream).Open(stream, readerOptions); // After: buffer applied after detection (fast) var factory = FindFactory<IArchiveFactory>(stream); stream = new SharpCompressStream(stream, bufferSize: readerOptions.BufferSize); return factory.Open(stream, readerOptions); ``` All 480 tests pass. <!-- START COPILOT CODING AGENT SUFFIX --> <details> <summary>Original prompt</summary> > > ---- > > *This section details on the original issue you should resolve* > > <issue_title>Decompression performance 7 times slower after updating from 0.31 to 0.32 +</issue_title> > <issue_description>Opening archives with ArchiveFactory.Open() seems to have a significant performance lose (around 7 times slower) after updating from 0.31 to 0.32 + versions. > > Anyone noticed any similar behavior? </issue_description> > > ## Comments on the Issue (you are @copilot in this section) > > <comments> > <comment_new><author>@adamhathcock</author><body> > Any details of what format used? > > I want to stick some profiling around the codebase soon</body></comment_new> > </comments> > </details> - Fixes adamhathcock/sharpcompress#879 <!-- START COPILOT CODING AGENT TIPS --> --- ✨ Let Copilot coding agent [set things up for you](https://github.com/adamhathcock/sharpcompress/issues/new?title=✨+Set+up+Copilot+instructions&body=Configure%20instructions%20for%20this%20repository%20as%20documented%20in%20%5BBest%20practices%20for%20Copilot%20coding%20agent%20in%20your%20repository%5D%28https://gh.io/copilot-coding-agent-tips%29%2E%0A%0A%3COnboard%20this%20repo%3E&assignees=copilot) — coding agent works faster and does higher quality work when set up for your repo. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
claunia added the pull-request label 2026-01-29 22:20:22 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
duplicate
enhancement
feedback requested
not bug
pull-request
Mirrored from GitHub Pull Request
 question
up for grabs
wontfix
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/sharpcompress#1397
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?