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 #384] [MERGED] Implemented ReadByte/WriteByte on streams to improve performance #1001

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

📋 Pull Request Information

Original PR: https://github.com/adamhathcock/sharpcompress/pull/384
Author: @MrJul
Created: 5/27/2018
Status: ✅ Merged
Merged: 5/28/2018
Merged by: @adamhathcock

Base: master ← Head: perf-readbyte

📝 Commits (1)

  • 540618c Implemented ReadByte/WriteByte on streams to improve performance

📊 Changes

17 files changed (+186 additions, -3 deletions)

View changed files

📝 src/SharpCompress/Common/EntryStream.cs (+10 -0)
📝 src/SharpCompress/Common/Tar/TarReadOnlySubStream.cs (+16 -0)
📝 src/SharpCompress/Compressors/BZip2/BZip2Stream.cs (+10 -0)
📝 src/SharpCompress/Compressors/BZip2/CBZip2InputStream.cs (+4 -0)
📝 src/SharpCompress/Compressors/BZip2/CBZip2OutputStream.cs (+5 -0)
📝 src/SharpCompress/Compressors/Deflate/DeflateStream.cs (+18 -0)
📝 src/SharpCompress/Compressors/Deflate/ZlibStream.cs (+18 -0)
📝 src/SharpCompress/Compressors/LZMA/Bcj2DecoderStream.cs (+16 -0)
📝 src/SharpCompress/Compressors/LZMA/LZipStream.cs (+8 -0)
📝 src/SharpCompress/Compressors/Xz/Filters/Lzma2Filter.cs (+5 -0)
📝 src/SharpCompress/Crypto/Crc32Stream.cs (+14 -1)
📝 src/SharpCompress/IO/CountingWritableSubStream.cs (+7 -1)
📝 src/SharpCompress/IO/ListeningStream.cs (+18 -0)
📝 src/SharpCompress/IO/NonDisposingStream.cs (+10 -0)
📝 src/SharpCompress/IO/ReadOnlySubStream.cs (+14 -0)
📝 tests/SharpCompress.Test/ForwardOnlyStream.cs (+7 -1)
📝 tests/SharpCompress.Test/Zip/Zip64Tests.cs (+6 -0)

📄 Description

NonDisposingStream and ReadOnlySubStream should implement ReadByte: currently they don't, and the default Stream implementation allocates a new one-byte buffer each time.

Stream.ReadByte() is used extensively by the LZMA decoder. With this simple change, I get a ~16-17% speed improvement on my machine while extracting all files in a 43MB LZMA-compressed zip file, and total memory allocations are cut by 1GB!

In the same fashion, I've also overridden CountingWritableSubStream.WriteByte to improve encoding. The speed results are marginal (2-3% improvement) since the encoding algorithm takes most of the CPU time, but they exist. Additional, memory traffic is also cut by a fair margin.

I've also implemented ReadByte/WriteByte on most SharpCompress streams where it was trivial to do so.

🔄 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/384 **Author:** [@MrJul](https://github.com/MrJul) **Created:** 5/27/2018 **Status:** ✅ Merged **Merged:** 5/28/2018 **Merged by:** [@adamhathcock](https://github.com/adamhathcock) **Base:** `master` ← **Head:** `perf-readbyte` --- ### 📝 Commits (1) - [`540618c`](https://github.com/adamhathcock/sharpcompress/commit/540618c0620fcf4b0261bf655c74023a2e9c784d) Implemented ReadByte/WriteByte on streams to improve performance ### 📊 Changes **17 files changed** (+186 additions, -3 deletions) <details> <summary>View changed files</summary> 📝 `src/SharpCompress/Common/EntryStream.cs` (+10 -0) 📝 `src/SharpCompress/Common/Tar/TarReadOnlySubStream.cs` (+16 -0) 📝 `src/SharpCompress/Compressors/BZip2/BZip2Stream.cs` (+10 -0) 📝 `src/SharpCompress/Compressors/BZip2/CBZip2InputStream.cs` (+4 -0) 📝 `src/SharpCompress/Compressors/BZip2/CBZip2OutputStream.cs` (+5 -0) 📝 `src/SharpCompress/Compressors/Deflate/DeflateStream.cs` (+18 -0) 📝 `src/SharpCompress/Compressors/Deflate/ZlibStream.cs` (+18 -0) 📝 `src/SharpCompress/Compressors/LZMA/Bcj2DecoderStream.cs` (+16 -0) 📝 `src/SharpCompress/Compressors/LZMA/LZipStream.cs` (+8 -0) 📝 `src/SharpCompress/Compressors/Xz/Filters/Lzma2Filter.cs` (+5 -0) 📝 `src/SharpCompress/Crypto/Crc32Stream.cs` (+14 -1) 📝 `src/SharpCompress/IO/CountingWritableSubStream.cs` (+7 -1) 📝 `src/SharpCompress/IO/ListeningStream.cs` (+18 -0) 📝 `src/SharpCompress/IO/NonDisposingStream.cs` (+10 -0) 📝 `src/SharpCompress/IO/ReadOnlySubStream.cs` (+14 -0) 📝 `tests/SharpCompress.Test/ForwardOnlyStream.cs` (+7 -1) 📝 `tests/SharpCompress.Test/Zip/Zip64Tests.cs` (+6 -0) </details> ### 📄 Description `NonDisposingStream` and `ReadOnlySubStream` should implement `ReadByte`: currently they don't, and [the default `Stream` implementation allocates a new one-byte buffer each time](https://source.dot.net/#System.Private.CoreLib/src/System/IO/Stream.cs,757). `Stream.ReadByte()` is used extensively by the LZMA decoder. With this simple change, I get a ~16-17% speed improvement on my machine while extracting all files in a 43MB LZMA-compressed zip file, and total memory allocations are cut by 1GB! In the same fashion, I've also overridden `CountingWritableSubStream.WriteByte` to improve encoding. The speed results are marginal (2-3% improvement) since the encoding algorithm takes most of the CPU time, but they exist. Additional, memory traffic is also cut by a fair margin. I've also implemented `ReadByte`/`WriteByte` on most SharpCompress streams where it was trivial to do so. --- <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:18:33 +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#1001
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?