Apache OpenOffice (AOO) Bugzilla – Issue 18380
extremely slow/low performance save, load, copy, paste, move etc with many objects
Last modified: 2017-05-20 11:29:54 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.
Created attachment 8561 [details] example "draw-killer" file
Created attachment 8562 [details] PDF export of prev document
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. http://framework.openoffice.org/documentation/mimetypes/mimetypes.html A little silly for issuezilla IMHO.
Hello, it seems you have attched the pdf file two times. Would it be possible to attach the sxd file again? Thanks in advance.
If have tested this with a similar file and handling indeed gets very slow.
Reassigned to Christian. Please have a look if there is something that can be done about the performance.
Created attachment 8565 [details] correct file - big grid map
Sorry, a few important things I forgot to mention: OS: Red Hat 8, Red Hat 9 OO.o versions: 1.1rc1, 1.1rc3
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
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.
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.
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.
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. Thanks
Reset assigne to the default "issues@openoffice.apache.org".