-
-
Notifications
You must be signed in to change notification settings - Fork 810
mount: fuse fs performance fix, docstring #9246
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mount: fuse fs performance fix, docstring #9246
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## 1.4-maint #9246 +/- ##
==========================================
Coverage 80.59% 80.59%
==========================================
Files 38 38
Lines 11256 11256
Branches 1771 1771
==========================================
Hits 9072 9072
Misses 1615 1615
Partials 569 569 ☔ View full report in Codecov by Sentry. |
7321daa to
da51e3d
Compare
da51e3d to
0017e34
Compare
### Performance Comparison: `bytearray.extend()` vs. Concatenation The efficiency difference between `meta.extend(bytes(N))` and `meta = meta + bytes(N)` stems from how Python manages memory and objects during these operations. #### 1. In-Place Modification vs. Object Creation - **`bytearray.extend()`**: This is an **in-place** operation. If the current memory block allocated for the `bytearray` has enough extra capacity (pre-allocated space), Python simply writes the new bytes into that space and updates the length. If it needs more space, it uses `realloc()`, which can often expand the existing memory block without moving the entire data set to a new location. - **Concatenation (`+`)**: This creates a **completely new** `bytearray` object. It allocates a new memory block large enough to hold the sum of both parts, copies the contents of `meta`, copies the contents of `bytes(N)`, and then reassigns the variable `meta` to this new object. #### 2. Computational Complexity - **`bytearray.extend()`**: In the best case (when capacity exists), it is **O(K)**, where K is the number of bytes being added. In the worst case (reallocation), it is **O(N + K)**, but Python uses an over-allocation strategy (growth factor) that amortizes this cost, making it significantly faster on average. - **Concatenation (`+`)**: It is always **O(N + K)** because it must copy the existing `N` bytes every single time. As the `bytearray` grows larger (e.g., millions of items in a backup), this leads to **O(N²)** total time complexity across multiple additions, as you are repeatedly copying an ever-growing buffer. #### 3. Memory Pressure and Garbage Collection - Concatenation briefly requires memory for **both** the old buffer and the new buffer simultaneously before the old one is garbage collected. This increases the peak memory usage of the process. - `extend()` is more memory-efficient as it minimizes the need for multiple large allocations and relies on the underlying memory manager's ability to resize buffers efficiently. In the context of `borg mount`, where `meta` can grow to be many megabytes or even gigabytes for very large repositories, using concatenation causes a noticeable slowdown as the number of archives or files increases, whereas `extend()` remains performant.
b6dfcc9 to
4eed3ec
Compare
|
Backport failed for Please cherry-pick the changes locally and resolve any conflicts. git fetch origin master
git worktree add -d .worktree/backport-9246-to-master origin/master
cd .worktree/backport-9246-to-master
git switch --create backport-9246-to-master
git cherry-pick -x 646f279062faad0b88c2feeff2e0d9a9cf675a2a 4eed3ecd5b378c8cd899fd3fe89df001f7d43a65 |
No description provided.