we switched over from OOo3.2 to LO 3.5.2 on RHEL (Centos) 5.8 x64. We use(d) the writer's mailmerge feature for printing mass mail. The datasources are csv files.
When we try to print the mailing, LO is incredible slow, resp. hangs completely. This happens when using a file with more than aprox. 500 records. Up to 500 records it takes minutes until the printing dialog appears. The highest amount of records we where able to print was 1500. But therefor we waited more than 6 minutes until the printing dialog appeared. With a "normal" mailing of 21000 records still after 40 minutes nothing happend! Because of this, we are unable to print our mailings. With OOo the same action (from selection dialog to print dialog) takes round about 2 or 3 seconds(!!!).
We tried different types of settings in LO. We increased the amount of memory, we disabled the java engine. We loaded the address records in a postgresql database, we imported the csv file in a Calc document and used this as datasource. But nothing changed. soffice.bin consumes 99.9% of a CPU, the "save monitor" (in the german version "Speichern-Monitor") appears with a transparent background (the rest of the selection dialog shines through) and nothing more happens.
We tried LO 18.104.22.168 with no success (nothing changed). T
As mentioned above we run on:
RHEL (Centos) x64 with kernel 2.6.18-308.16.1.el5
LibreOffice 22.214.171.124 x32 (RPM)
36GB of memory
Created attachment 69054 [details]
Screenshot of the hanging status monitor of mailmerge
At the situation shown in the screenshot, no more other screen updates from LO are done/possible. Starting an new writer/calc/impress window is possible, but the window isn't shown, no entries/editing is possible.
Created attachment 69055 [details]
Screenshot what happens when status monitor is moved around
This screenshot shows what happens to the screen when you move the "hanging" status monitor around the screen.
Hi. I first created an .ods spreadsheet with 2000 records, and created a form letter using title, name, address, etc for fields. I printed to file without issue. It took several minutes (5-6), but LibreOffice did not hang, and the print out completed.
I then created a csv file with 22,000 records. I printed this to file, as well. It took 1 hour and 20 minutes, and never froze. The printout dialog constantly showed the next number of record it was printed. (Example: Printing 1000...Printing 1001...Printing 1002). During this time, LibreOffice used anywhere from 40-60% CPU. I was able to use other applications, including other LibreOffice products, except Writer, during this time. Trying to open and edit a Writer document was very sluggish, and I didn't spend too much time with that. It did not cause any crash or freezing. I did experience that moving the print dialog in Libre Office would result in showing the incremental movements.
In opening the resulting printout, LibreOffice Writer was very sluggish, and would use about 100% CPU.
Created attachment 74889 [details]
csv file with 22000 records
Created attachment 74890 [details]
printout of mail merge using 22000 records
I ran my tests using LibreOffice 126.96.36.199+ on 64-bit Ubuntu 12.04 LTS.
I'm not a hardware guru, but here are specs from my System Details, if it's of help:
AMD FX(tm)-4100 Quad-Core Processor × 4
Jan-Marek Glogowski at the Freiburg Hackfest created a callgrind trace of mailmerge, its available here:
(In reply to comment #7)
> Jan-Marek Glogowski at the Freiburg Hackfest created a callgrind trace of
> mailmerge, its available here:
And submitted a patch http://cgit.freedesktop.org/libreoffice/core/commit/?id=13a8fac05425f9d66c643f25faa49c1f17c62474 :).
@Björn: can we mark this one as fixed?
@Jorendc: indeed ;)
Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "master":
The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
Affected users are encouraged to test the fix and report feedback.
Ok. Will test it next week. In the current master as of "master~2013-11-20_23.55.57..." the patch seems still not to be included. The mail merge runs as slow as always. But i took the test to make a note of the elapsed time of the current master and will compare it next week with the patched master.
Just to make it clear - the patch doesn't speed up MM per-se. This just postpones the layouting of the generated _single_ MM document, so it takes constant time per document to generate, instead of the increasing time to relayout the whole combined document for every appended MM document.
Still not sure, if my MM problem is the same then yours (me running MM via Uno from WollMux).
As of the last daily master (4.3.0) from 25. Nov. there is no increased speed. All is the same as initially reported. The only thing changed is, that the printing monitor now (since 4.1.x) shows the progress again. So the user can see work in progress.
Printing a mass mail with 21.000 records still takes more than 90 minutes to bring up the printing dialog and again 90 minutes to start sending the output to the printer.
I found that "Format - Bullets and Numbering" in the source document make MM becomes slower an slower with every MM document.
LibreOffice 4.1.3 an 4.2.1
as temporary bandage, one can of course split large datasets in more batches.
I did sets with few thousands records some years back. Was indeed slow.
*** Bug 79067 has been marked as a duplicate of this bug. ***
> I found that "Format - Bullets and Numbering" in the source document
> make MM becomes slower an slower with every MM document.
Perhaps some lovely issue with outline numbering across all the documents then (?)
Anyone tested this in a recent version?
It's not fixed yet, but my patch is an improvement for some simple document types. People are still working on this.
This bugreport actually does not provide any testcase to reproduce the specific problem, so since I've just speeded up MM quite a bit in master, let's close this, as without further info it cannot be checked if this specific case is still slow or not.
(In reply to Lubos Lunak from comment #19)
> This bugreport actually does not provide any testcase to reproduce the
> specific problem, so since I've just speeded up MM quite a bit in master,
> let's close this, as without further info it cannot be checked if this
> specific case is still slow or not.
There is test document and spreadsheet attached to the duplicate bug 79067 we opened.
That one performs reasonably well now.