I did a performance-test with the following possible mechanismns to get the same mail merge result (mailmerge in to a file) out of the same input files (an .odt main-document and a .ods data table):

1) Mail Merge via Tools->Mail Merge Wizard

2) Mail Merge via File->Print->YES (print into file)

3) Mail Merge via API-Service css.text.MailMerge 

The result is, that all three mechanism seems to be implemented different and have different timings/performance.

Winner was Mail Merge Wizard, Second the API-Service and last File->Print. File->Print is over 20% slower than the Mail Merge Wizard. See attached pdf-document with the measured timings and a small diagram.

From other experiences I got with the OOo-Mail Merge I also know, that File->Print uses a temporary file in /tmp/<dir>/sv.*tmp where as the Mail Merge Wizard uses a newly created empty document (in memory) instead for each processed database entry. So the mechanism diverge not just in timing, but also in the implementation details. 

The enhancement should be to consolidate the three mechanism into one mechanism with the same algorithm and performance. The new mechanism should be aligned to the faster mechanism of the Mail Merge Wizard. The mechanisms 2) and 3) will be accelerated by that enormously. The corresponding three diverging parts of the writer-code will be consolidated into one and easier to maintain.

Find attached the following files:

a) the input-files for my timing-test brief.odt and brief.ods

b) the test-result overview (durationOfMailMergeJobs.pdf)

c) the small test-program I used to serve the API (needed for mechanism 3))