starred/sharpcompress
1
0
Fork 0
mirror of https://github.com/adamhathcock/sharpcompress.git synced 2026-02-09 05:24:55 +00:00
Code Issues 975 Packages Projects Releases 20 Wiki Activity

[PR #897] [MERGED] Implement ReadByte for BufferedSubStream #1319

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

📋 Pull Request Information

Original PR: https://github.com/adamhathcock/sharpcompress/pull/897
Author: @Morilli
Created: 2/16/2025
Status: ✅ Merged
Merged: 2/17/2025
Merged by: @adamhathcock

Base: master ← Head: bufferedsubstream-readbyte

📝 Commits (2)

  • 441147c Implement ReadByte for BufferedSubStream
  • 2411f4f Merge branch 'master' into bufferedsubstream-readbyte

📊 Changes

1 file changed (+24 additions, -0 deletions)

View changed files

📝 src/SharpCompress/IO/BufferedSubStream.cs (+24 -0)

📄 Description

I noticed absurd memory allocations when decompressing 7-zip files and tracked it down to BufferedSubStream not overriding ReadByte.
From the documentation: The default implementations of ReadByte() and WriteByte(Byte) create a new single-element byte array, and then call your implementations of Read(Byte[], Int32, Int32) and Write(Byte[], Int32, Int32). When you derive from Stream, we recommend that you override these methods to access your internal buffer, if you have one, for substantially better performance.

Testing with a ~300MB (compressed size) 7-zip file, I noticed an improvement in decompression speed from ~32 seconds to ~27 seconds and a reduction in memory allocations from ~7GB to ~100MB.

🔄 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/897 **Author:** [@Morilli](https://github.com/Morilli) **Created:** 2/16/2025 **Status:** ✅ Merged **Merged:** 2/17/2025 **Merged by:** [@adamhathcock](https://github.com/adamhathcock) **Base:** `master` ← **Head:** `bufferedsubstream-readbyte` --- ### 📝 Commits (2) - [`441147c`](https://github.com/adamhathcock/sharpcompress/commit/441147c0dc7a894a74e95d666c2d13ec1d6c9cf1) Implement ReadByte for BufferedSubStream - [`2411f4f`](https://github.com/adamhathcock/sharpcompress/commit/2411f4f8706b5fc6cd7f6298806af19a9058fc98) Merge branch 'master' into bufferedsubstream-readbyte ### 📊 Changes **1 file changed** (+24 additions, -0 deletions) <details> <summary>View changed files</summary> 📝 `src/SharpCompress/IO/BufferedSubStream.cs` (+24 -0) </details> ### 📄 Description I noticed absurd memory allocations when decompressing 7-zip files and tracked it down to `BufferedSubStream` not overriding `ReadByte`. From the [documentation](https://learn.microsoft.com/en-us/dotnet/api/system.io.stream?view=net-9.0): `The default implementations of ReadByte() and WriteByte(Byte) create a new single-element byte array, and then call your implementations of Read(Byte[], Int32, Int32) and Write(Byte[], Int32, Int32). When you derive from Stream, we recommend that you override these methods to access your internal buffer, if you have one, for substantially better performance.` Testing with a ~300MB (compressed size) 7-zip file, I noticed an improvement in decompression speed from ~32 seconds to ~27 seconds and a reduction in memory allocations from ~7GB to ~100MB. --- <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:19:57 +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#1319
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?