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

• 394 messaging tests and writer doctests passed.
• Added tests for UTF-8 and Latin-1, contexts, plural forms, fuzzy and untranslated entries, string-table offsets and terminators, and writing a bytes object once.
• 414 before/after output and error comparisons matched: 336 produced identical output bytes and 78 produced the same errors, including encoding failures and failed output writes.
• The full-suite run on this PC had 7,832 passes, two failures, nine skips and two expected failures. Both failures were the timezone-name test parametrizations comparing GMT+00:00 with GMT+05:30; they also failed with the original writer.
• Ruff checks passed for the changed code and 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.

Public fixture sources:

• Django German (unchanged contents; source SHA256 in JSON).
• Wagtail German (unchanged contents; source SHA256 in JSON).
• Wagtail French (unchanged contents; source SHA256 in JSON).