starred/sharpcompress
1
0
Fork 0
mirror of https://github.com/adamhathcock/sharpcompress.git synced 2026-02-12 13:35:11 +00:00
Code Issues 975 Packages Projects Releases 22 Wiki Activity

[PR #912] [MERGED] Optimize BufferedSubStream.ReadByte #1343

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

📋 Pull Request Information

Original PR: https://github.com/adamhathcock/sharpcompress/pull/912
Author: @jdpurcell
Created: 3/25/2025
Status: ✅ Merged
Merged: 3/25/2025
Merged by: @adamhathcock

Base: master ← Head: pr-bss-optim

📝 Commits (1)

  • a7918d7 Optimize BufferedSubStream.ReadByte

📊 Changes

1 file changed (+27 additions, -27 deletions)

View changed files

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

📄 Description

In BufferedSubStream, by changing what BytesLeftToRead and _cacheLength track, we can simplify the work to be done when reading a byte. BytesLeftToRead now tracks the amount of completely unread/uncached data, and _cacheLength tracks the total cache length including the consumed portion. Then we only need to update the cache offset when reading a byte. It also moves the logic to refresh the cache into its own method. Interestingly, only about half of the performance increase comes from simplifying the variable usage. The other half comes from moving out the cache refresh logic, presumably because it makes the ReadByte method small enough for callers to inline.

Core i7-6700k (1.7% reduction):

Method Mean Error StdDev
Before 1.088 s 0.0031 s 0.0028 s
After 1.070 s 0.0011 s 0.0010 s

Apple M3 (2.8% reduction):

Method Mean Error StdDev
Before 785.0 ms 1.60 ms 1.42 ms
After 763.2 ms 2.84 ms 2.52 ms

Time to extract a 14MB 7z. The benchmarks are with .NET 8.0 but it also helped slightly with .NET Framework 4.8 (~1.1% reduction).

I wish I could keep going with these optimization PRs but I think I'm out of ideas after this one 😄.

🔄 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/912 **Author:** [@jdpurcell](https://github.com/jdpurcell) **Created:** 3/25/2025 **Status:** ✅ Merged **Merged:** 3/25/2025 **Merged by:** [@adamhathcock](https://github.com/adamhathcock) **Base:** `master` ← **Head:** `pr-bss-optim` --- ### 📝 Commits (1) - [`a7918d7`](https://github.com/adamhathcock/sharpcompress/commit/a7918d7b1164601ebb0cc22b01331485c1e830f2) Optimize BufferedSubStream.ReadByte ### 📊 Changes **1 file changed** (+27 additions, -27 deletions) <details> <summary>View changed files</summary> 📝 `src/SharpCompress/IO/BufferedSubStream.cs` (+27 -27) </details> ### 📄 Description In `BufferedSubStream`, by changing what `BytesLeftToRead` and `_cacheLength` track, we can simplify the work to be done when reading a byte. `BytesLeftToRead` now tracks the amount of completely unread/uncached data, and `_cacheLength` tracks the total cache length including the consumed portion. Then we only need to update the cache offset when reading a byte. It also moves the logic to refresh the cache into its own method. Interestingly, only about half of the performance increase comes from simplifying the variable usage. The other half comes from moving out the cache refresh logic, presumably because it makes the `ReadByte` method small enough for callers to inline. Core i7-6700k (1.7% reduction): | Method | Mean | Error | StdDev | |------- |--------:|---------:|---------:| | Before | 1.088 s | 0.0031 s | 0.0028 s | | After | 1.070 s | 0.0011 s | 0.0010 s | Apple M3 (2.8% reduction): | Method | Mean | Error | StdDev | |------- |---------:|--------:|--------:| | Before | 785.0 ms | 1.60 ms | 1.42 ms | | After | 763.2 ms | 2.84 ms | 2.52 ms | Time to extract a 14MB 7z. The benchmarks are with .NET 8.0 but it also helped slightly with .NET Framework 4.8 (~1.1% reduction). I wish I could keep going with these optimization PRs but I think I'm out of ideas after this one 😄. --- <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:05 +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#1343
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?