Repository navigation
Speed up MO file writing - #1376
Open
harshitgupta31415 wants to merge 1 commit into
Open
harshitgupta31415 wants to merge 1 commit into
harshitgupta31415 wants to merge 1 commit into
Conversation
akx
requested changes
Oct 26, 2026
akx
left a comment
Member
There was a problem hiding this comment.
Please remove the new tests, I don't think they're necessary?
harshitgupta31415
force-pushed
the
harshitgupta31415/speed-up-mo-file-writing
branch
from
October 26, 2026 05:20
4cb2f41 to
c8096ba
Compare
Contributor
Author
|
@akx updated as per your request. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #1376 +/- ##
=======================================
Coverage 93.51% 93.51%
=======================================
Files 27 27
Lines 4932 4933 +1
=======================================
+ Hits 4612 4613 +1
Misses 320 320
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
akx
approved these changes
Oct 26, 2026
Use separate bytearray buffers for message ids and translations instead of rebuilding bytes objects for each entry. Keep the same offsets and final bytes write.
akx
force-pushed
the
harshitgupta31415/speed-up-mo-file-writing
branch
from
October 26, 2026 05:22
c8096ba to
acb11a9
Compare
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
write_mo builds two byte strings as it adds each message. Each append copies the content already in that string, so larger catalogs spend more time copying earlier messages.
This changes those two buffers to separate bytearrays. The rest of the function stays the same: it filters and sorts the same messages, calculates the same offsets, and makes one write with a bytes object.
For similarly sized messages, building the string tables goes from quadratic copying to linear work. Sorting is unchanged. This does not remove all allocation costs, and peak memory is slightly higher in the measured cases.
Tests
Benchmarks
I measured the complete write_mo call on Python 3.15.0 and Windows 11, using the median of eight timing runs and eight separate peak-allocation runs per version. The base was e2a1791.
Catalog construction, PO parsing, downloads and output checks were outside the timer. Each call wrote to a fresh BytesIO. One process was limited to two physical cores at a time; core pairs rotated between repeats, paired versions used the same pair, and their order alternated. Memory below is newly traced Python allocations during the write, not total process RAM.
There are 100 generated catalog examples, two empty-catalog controls, and six cases using unchanged Django and Wagtail catalogs. The real-project cases measured 1.09×–1.48× faster. Tiny cases sometimes measured slower, and small differences can be noise. All 108 cases, including slower results and memory increases, are included below.
The runner, CPU helper, raw samples and rerun instructions are on a separate branch in my fork, so they do not add files to this PR.
Show all 108 measured cases
Public fixture sources: