Issue 18380 - extremely slow/low performance save, load, copy, paste, move etc with many objects
Summary: extremely slow/low performance save, load, copy, paste, move etc with many ob...
Alias: None
Product: Draw
Classification: Application
Component: ui (show other issues)
Version: OOo 1.1 RC3
Hardware: PC Linux, all
: P3 Trivial with 6 votes (vote)
Target Milestone: AOO Later
Assignee: AOO issues mailing list
QA Contact:
Keywords: oooqa, performance
Depends on:
Reported: 2003-08-19 06:58 UTC by ringerc
Modified: 2017-05-20 11:29 UTC (History)
6 users (show)

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

example "draw-killer" file (280.28 KB, application/octet-stream)
2003-08-19 07:01 UTC, ringerc
no flags Details
PDF export of prev document (280.28 KB, application/pdf)
2003-08-19 07:02 UTC, ringerc
no flags Details
correct file - big grid map (139.59 KB, application/octet-stream)
2003-08-19 08:40 UTC, ringerc
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description ringerc 2003-08-19 06:58:10 UTC
Hi all

I was creating a large (A0) hex map for a friend, and I've discovered a serious
performance problem.

As the number of objects on the page increases, performance appears to decrease
very rapidly. It doesn't appear to be exponential, but it's at least linear, and
the impact of each increase is significant.

I have a 140k draw document, composed of a regular grid of hexagons (that was a
pain to create), each of which has all 6 faces numbered. Seven objects per hex,
well over a thousand hexes, so we're looking at probable more than 10k objects.
That's a fair few, but not impossibly huge for a vector drawing document. I
found that before I'd covered 1/4 of the page, it was becoming sufficiently slow
to navigate around the page, move objects, etc as to be very hard to use. The
system I was using was an Athlon 1800+(1.5GHz) with 768MB of RAM and 7200RPM
HDDs, so I would expect it to be quite fast enough.

I was only able to complete the document by moving to a dual Xeon at work (dual
2.4GHz Xeon, 2GB RAM, RAID5 + RAID 1 arrays).

I'll attach the document as an example.

To reproduce this issue, just create a document and begin populating it with
objects. Once you have a few, copy them, paste them, select the new group, copy
that, etc. Double at each repition, in other words. That was how the hex grid
was created - making one hex, then a group of 7, then a column the height of the
page, then doubling that across the width of the page.

I find it telling that while it took almost a minute to save on the Xeon, a PDF
was created in about 10s (also attached).

Separate to this issue, but worth mentioning since you'll see it, is the fact
that in some places the text labels obscure the hex lines. Sometimes the edges
of the hexes don't seem to line up perfectly all the time either, but that may
be an issue with the way I created the document. That is not really important
wrt to this bug, however.
Comment 1 ringerc 2003-08-19 07:01:20 UTC
Created attachment 8561 [details]
example "draw-killer" file
Comment 2 ringerc 2003-08-19 07:02:32 UTC
Created attachment 8562 [details]
PDF export of prev document
Comment 3 ringerc 2003-08-19 07:05:56 UTC
Bugzilla needs to be updated to recognise the MIME types in the
application/vnd.sun.xml.* range. It just rejected
'application/vnd.sun.xml.draw' for the MIME type of the attachment I
just sent.

A little silly for issuezilla IMHO.
Comment 4 wolframgarten 2003-08-19 08:13:35 UTC
it seems you have attched the pdf file two times. Would it be 
possible to attach the sxd file again? Thanks in advance.
Comment 5 wolframgarten 2003-08-19 08:27:20 UTC
If have tested this with a similar file and handling indeed gets very 
Comment 6 wolframgarten 2003-08-19 08:28:06 UTC
Reassigned to Christian. Please have a look if there is something 
that can be done about the performance.
Comment 7 ringerc 2003-08-19 08:40:48 UTC
Created attachment 8565 [details]
correct file - big grid map
Comment 8 ringerc 2003-08-19 08:54:43 UTC
Sorry, a few important things I forgot to mention:

OS: Red Hat 8, Red Hat 9
OO.o versions: 1.1rc1, 1.1rc3
Comment 9 clippka 2003-08-26 12:43:36 UTC
armin, I think this might be a good case to check performance
enhancements in your new drawing layer aproach. Please send to me
afterwards so I can do some xml file profiling on this case later
Comment 10 Armin Le Grand 2003-09-12 14:21:14 UTC
AW->CL: Yes, indeed. Loading with a src680m5 even leads to a
application error. With my new local version with half-changed
DrawingLayer i can load and do something (!). So, from my side this
one is in progress, but i will keep an eye on documents with lot of
objects. Please send back when load/save is faster.
Comment 11 ringerc 2003-09-23 14:14:59 UTC
Just for comparison, I've just done some additional testing with
StarOffice 7 (eval). It's still apallingly slow to load - 1m 45s on my
Athlon 1.5GHz. OpenOffice 1.1rc4 takes 1m 54s, so I'd call them much
the same. StarOffice seems to redraw a little faster when scolling
around, though.

It doesn't look like Sun have made any XML handling improvements that
affect draw, anyway.

To be honest, the load/save time isn't too bad compared to the time it
takes to scroll around, copy elements, and paste elements in this
document - those make it almost impossible to work on.
Comment 12 clippka 2003-09-29 13:00:42 UTC
since xml performance is no goal for OOo 2.0 and armin is working on
improving the performance while editing a document with a huge amount
of objects, I will keep this task for later investigation when there
is time.
Comment 13 utomo99 2008-01-04 12:39:33 UTC
This performance problems did not get any new things since 2003, and now 
already 2008 (5 years)
I hope we can have better performance. 
as many people complains about OOo performance. 

Comment 14 Marcus 2017-05-20 11:29:54 UTC
Reset assigne to the default "".