https://bugs.documentfoundation.org/show_bug.cgi?id=173573
Bug ID: 173573
Summary: PERF: DOCX table row splitting with minimum row height
and vertical centering is slower in 26.8 than 7.4
Product: LibreOffice
Version: 26.8.0.3 release
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: Writer
Assignee: [email protected]
Reporter: [email protected]
# Writer DOCX performance regression: table row splitting with minimum height
and vertical centering (7.4.7.2 vs 26.8.0.3)
Product: LibreOffice
Component: Writer
Platform: x86-64 Linux (Debian 12)
Version tested: 26.8.0.3 release
Last known good comparison: 7.4.7.2 (intermediate versions not bisected)
Suggested keywords: perf, regression
## Summary
A DOCX containing a long table loads/converts considerably more slowly in
26.8.0.3 than in 7.4.7.2. The table combines minimum row heights, vertically
centered cells, vertical merges, and rows allowed to split across pages.
Disabling row splitting for that table avoids most of the cost. This is a
layout-changing workaround, not an acceptable transparent fix for arbitrary
documents.
The attached reduction contains only placeholder text and a newly created DOCX
package; it contains no customer content, metadata, images, embedded objects,
or external relationships. It retains one 107-row, two-column table plus
placeholder paragraphs. Minimum row height is 585 twips. The left column has 52
vertical merge groups of two rows and vertical centering.
## Reproduction without Java/JODConverter
With a fresh user profile, run the attached repro.sh using the path to each
version's soffice and table-layout-repro.docx. It uses --headless --convert-to
PDF with UseTaggedPDF=false. Repeat with table-layout-no-row-split.docx, which
adds cantSplit to the 107 rows.
Example:
./repro.sh /opt/libreoffice26.8/program/soffice table-layout-repro.docx
./repro.sh /opt/libreoffice7.4/program/soffice table-layout-repro.docx
./repro.sh /opt/libreoffice26.8/program/soffice
table-layout-no-row-split.docx
## Measurements
On the same Debian 12 x86-64 environment, same fonts and machine:
| Input | Version | CLI wall time including process startup |
|---|---|---:|
| Placeholder reproduction | 7.4.7.2 | 2.04 s |
| Placeholder reproduction | 26.8.0.3 | 3.86 s |
| Placeholder reproduction with cantSplit | 26.8.0.3 | 1.23 s |
Separately, using a prestarted headless Office process through JODConverter
4.4.11, with the default document refresh and UseTaggedPDF=false:
| Input | Version | Load | Refresh | PDF export | Total |
|---|---|---:|---:|---:|---:|
| Placeholder reproduction | 7.4.7.2 | 465 ms | 22 ms | 255 ms | 741 ms |
| Placeholder reproduction | 26.8.0.3 | 3109 ms | 55 ms | 180 ms | 3344 ms |
| Placeholder reproduction with cantSplit | 26.8.0.3 | 381 ms | 27 ms | 144 ms
| 553 ms |
These are individual controlled runs, not a statistical benchmark. CLI figures
include startup and must not be compared directly to the prestarted-process
figures.
The larger private source document (not attached) showed 7.81 s vs 36.82 s;
36.41 s of the latter was load time. A cantSplit-only variant completed in
1.09–1.10 s across three independent fresh-process runs. Reducing and replacing
text changes the layout and reduces the absolute cost, but the version
difference and row-split workaround remain reproducible in the public
attachment.
## Expected / actual
Expected: layout and conversion should finish promptly without a large
regression, while preserving the requested row splitting, minimum heights, and
vertical alignment.
Actual: most time is spent during loading/layout. Three debugger samples on the
larger source document passed through SwTabFrame::MakeAll,
SwContentFrame::CalcLowers and SwTextFrame::Format. The sanitized stack excerpt
is attached. No REF fields or images are involved.
## Additional isolation on the larger source document
- Removing this table reduces 26 conversion from 36.82 s to 3.31 s.
- Keeping this table and deleting other tables still takes 37.14 s.
- Removing minimum row heights from this table: 3.02 s.
- Removing vertical centering from this table: 1.57 s.
- Removing vertical merge markers alone: still 33.10 s.
- Setting explicit column widths: still 36.96 s.
- Temporarily removing vertical alignment for import and restoring it before
export moves the cost into relayout (38.74 s total), rather than fixing it.
- Turning off image downsampling has no benefit; the document has no images.
The formatting workarounds alter text placement/pagination and are not lossless
fixes. We prefer a correction in LibreOffice's layout engine.
## Related reports, not confirmed duplicates
- Bug 167313 (comment 42): high CPU / repeated pagination, improved by
disabling table/row splitting and keep-with-next. The report was NEW when
checked on 2026-09-16.
- Bug 161508 and subsequent 165156: row-height/layout oscillation. Related
existing loop-control code is present in the 26.8.0.3 source, yet this sample
is still slow.
Please help determine whether this is a duplicate or another regression, and
identify the first release containing any eventual fix.
## Version details
LibreOffice 7.4.7.2: 723314e595e8007d3cf785c16538505a1c878ca5
LibreOffice 26.8.0.3: bce0998afefdbc355585ca324285661a2170ba77
Linux x86-64, Debian 12, headless, LANG=zh_CN.UTF-8.
Java-specific isolation used Java 8 and JODConverter 4.4.11; the CLI
reproduction above does not require either.
--
You are receiving this mail because:
You are the assignee for the bug.
