Issue 54531 - Performance: Creating documents with Mail Merge WIzard is too slow
Summary: Performance: Creating documents with Mail Merge WIzard is too slow
Status: CLOSED DUPLICATE of issue 40827
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: 680m128
Hardware: All All
: P3 Trivial (vote)
Target Milestone: AOO Later
Assignee: Oliver Specht
QA Contact: issues@framework
URL:
Keywords: oooqa, performance
Depends on:
Blocks:
 
Reported: 2005-09-13 08:29 UTC by joerg.skottke
Modified: 2008-06-12 07:46 UTC (History)
9 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description joerg.skottke 2005-09-13 08:29:22 UTC 
Automated test: f_updt_mailmerge::tUpdtMailmerge

On a Pentium III 500 / 512 MB RAM creating documents takes an average of three
seconds per recipient. This is too slow.
Comment 1 phillg 2005-10-12 13:19:44 UTC 
Confirming on AMD64 2000+ w/ 1gb ram, m130

Produced 16 labels (one sheet) from a MySQL DB that has 750 rows and it took 43
seconds from clicking OK (after File > Print > Form Letter) to the printing
labels dialogue to come up (which was displayed for less than a second).

Copied the DB and dropped all bar 32 records.  Closed OOo and reopened it and
attempted to print the same 16 labels on one sheet again, this time it only took
17 seconds.  

Repeated the tests to confirm the times.

Surely this suggests that OOo is merging the entire database rather than just
the requested fields...?
Comment 2 utomo99 2008-01-04 13:10:31 UTC 
since 2005 this problems still no news. and now 2008. 
many people complains about OOo performance. 
I hope we can reduce the performance problems, so it will reduce the complains 
also. 

Thanks
Comment 3 robbk 2008-01-07 06:48:35 UTC 
I second what utomo99 said.
Comment 4 mfn 2008-02-21 15:27:18 UTC 
copy that
Comment 5 cno 2008-06-11 20:54:30 UTC 
shouldn  this one be set as dup of issue 40827 ?
Comment 6 Oliver Specht 2008-06-12 07:45:42 UTC 
Setting as duplicate

*** This issue has been marked as a duplicate of 40827 ***
Comment 7 Oliver Specht 2008-06-12 07:46:05 UTC 
Closing