Bug 54722 - Draw slow for .odg with tenthousands of shapes
Summary: Draw slow for .odg with tenthousands of shapes
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
3.5.4 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: perf
Depends on:
Blocks: Draw-UX
  Show dependency treegraph
 
Reported: 2012-09-10 10:06 UTC by Ferry Toth
Modified: 2018-06-17 12:19 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
zip file containing original pdf (2.23 MB, application/x-zip-compressed)
2012-09-10 10:07 UTC, Ferry Toth
Details
resulting drawing after conversion (930.83 KB, application/vnd.oasis.opendocument.graphics)
2012-09-10 10:07 UTC, Ferry Toth
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ferry Toth 2012-09-10 10:06:24 UTC
One of the great things about Draw is that it can open PDF files.

A common task for electronic engineers is to document their schematic and layout designs, typically in a Writer document. However most schematic entry/layout software don't export formats that word processors can import, except bitmaps. But these can't be edited with comments/modifications to improve clarity etc.

In the case below I create gerber files (an old format based on pen coordinates and a standard format in the industry), then view these in a gerber viewer (GC-Preview in this case). I print the output to a pdf file using our cups-pdf printer (see following zip file '120024 sample layout.pdf.zip').

Then importing to draw I get '120024 sample layout.odg'.

Now working on the drawing is virtually impossible due to the excessive memory use (after a while) and really terrible slowness of Draw. See metrics below.

I expect the problem happens because draw has not really been tested using a drawing  with many objects (~100000). Therefore I am donating the attached layout files, that are copyright our company for the purpose of testing/improving Draw to the community.

zip file 2.2MiB, pdf file 24.5MiB after conversion to odg: 930kiB.
system: quad core 2664MHz, LO using 1 core.
open/conversion time for pdf->odg: 10 minutes
save time odg: 2 minutes
#object on page 8: 63608
with anti-aliasing (AA) off drag/move all on page 8: 25 sec.
turn on AA: 20 sec.
with anti-aliasing (AA) on drag/move all on page 8: 105 sec.
memory use at this point: 530748kiB.

I think that these files can be used as a test case to find inefficiencies in Draw's code. Resolving these will improve the performance for all users.

Ferry
Comment 1 Ferry Toth 2012-09-10 10:07:19 UTC
Created attachment 66916 [details]
zip file containing original pdf
Comment 2 Ferry Toth 2012-09-10 10:07:56 UTC
Created attachment 66918 [details]
resulting drawing after conversion
Comment 3 Hashem Masoud 2012-10-25 14:15:50 UTC
Confirmed. Performance is extremely low here as well. My system specs are also lower than the one you listed.
Comment 4 Timur Aitov 2013-02-13 11:19:28 UTC
Hi, everyone!

I met the same problem (Slow move object in document with many objects)... Did anyone try to solve this problem?

TY
Comment 5 Rainer Bielefeld Retired 2013-04-15 10:03:26 UTC
More or less  [Reproducible] with reporter's sample.odg and parallel Dev-installation of  "Version 4.1.0.0.alpha0+ (Build ID: 049ce78144650d92eb6bd73292868f73d37c901) TinderBox: Win-x86@6, Branch:master, Pull Time: 2013-03-29_23:59:42" ENGLISH UI / German Locale on German WIN7 Home Premium (64bit) with LODev/4 Masters User Profile. More or less unusable, even stops responding after a while. Tub it's a question if LibO should be designed for 100-thousand shapes drawings?

Currently I see this one as a low priority enhancement request.

@Ferry Toth
Thank you for the sample document, of course, performance can't be too much, but it's a weighing where we want to invest developers' manpower, and currently I see too many "does not work at all" bugs with priority before "should work faster".

@Hashem Masoud, Timur Aitov, Ferry Toth:
please contribute info concerning your OS?
Can someone do a test with 1-3 older versions? I doubt that that was faster in the past, but yo never know, if we find out that that was lightning fast with OOo 2 that might help to find a solution.

Additional info required here in the bug:
a) is this really LibO 3.5.4 problem? I doubt that any more early LibO or OOo version has been faster
b) all OS related (I think so, but it has not been written here)?
Comment 6 Rainer Bielefeld Retired 2013-04-15 11:34:54 UTC
All tests: WIN7 64bit, with hardware acceleration where applicable.

After 2 minutes of loading OOo 1.1.5 really works fine, I did several smaller edits in Shape 1 withou any  problems, works very fast. No significant CPU load, 250MB Memory

Similar with OOo 2.0.3, but here smaller delays between edits, when I selected a shape and want to select an other one I always have to wait some annoying 1/10 seconds

AOOo 3.4.0 very similar to OOo 2.0.3, Anti-Aliasing-off brings some speedup.

LibO 3.3.3 needs 500MB Memory, 1/4 speed or less compared to AOOo 3.4.0, any edit brings up maximum CPU load for some seconds, more or less unusable. I can't see significant progress without anti aliasing

LibO 3.5.7 similar to 3.6.6 (see below

LibO 3.6.6 needs 500MB Memory, but works fine, somewhere between OOo 1.1.5 and 2.0.3

Only 400MB Memory with parallel Dev-installation of  "Version 4.1.0.0.alpha0+ (Build ID: 049ce78144650d92eb6bd73292868f73d37c901) TinderBox: Win-x86@6, Branch:master, Pull Time: 2013-03-29_23:59:42" ENGLISH UI / German Locale on German WIN7 Home Premium (64bit) with LODev/4 Masters User Profile, rest similar.
Comment 7 Ferry Toth 2013-04-15 19:29:23 UTC
Hello Rainer,

Thank you for comparing the results for different versions. Never tried it on 1.15 myself. My history only goes back to 2.04.

I completely understand the workload is excessive and will never be lightning fast for this test case.

My understanding is that the AA code is being or has recently been optimized and this is the major purpose of uploading my document. To provide a test case that makes it very measurable when a performance increase or decrease is achieved.
The most difficult page to edit is page 8 (63000 object), which is the one I used for testing, the other pages are somewhere around 10000.

I am on 3.6.2 now (Kubuntu Quantal x64), this machine dual core 3GHz.
With AA off 22sec. (same as my previous test).
With AA on 32sec. (more then 3x faster then my previous test).

The AA code has been tremendously improved, me very happy.

Can we conclude that the non-AA code regressed going from 2.0.3 to 3.3.3?

Ferry
Comment 8 Robinson Tryon (qubit) 2015-12-09 18:07:51 UTC Comment hidden (obsolete)
Comment 9 Heiko Tietze 2016-06-21 12:44:38 UTC
About one minute to open, one or two seconds to move shapes around. Please try again, there has been done a lot in the past (e.g. https://wiki.documentfoundation.org/OpenGL). Please close the ticket if you are satisfied, I set NEEDINFO since it's an old ticket. Setting component to normal since processing speed is no enhancement.

Version: 5.3.0.0.alpha0+ (x64)
Build ID: f536a83d51443d19dba58157cea28fb67a090e02
CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; 
TinderBox: Win-x86_64@62-TDF, Branch:MASTER, Time: 2016-06-13_01:19:21
Locale: de-DE (de_DE)

i5-2540M, 8GB RAM, W7-64bit
Comment 10 Ferry Toth 2016-06-21 13:57:13 UTC
We are now 4 years later, so my processor improve to i7-3770 @ 3.4GHz.

Opening the file now takes 40 sec, moving after selecting everything on page 8 takes 35 sec.

I wouldn't want to close this as I think the attachments are being used as test case to check for regressions.

Also, even though the improvement has been substantial, there is probably more that could be done.

For instance, importing (not opening) page 8 of the PDF into Inkscape takes 20sec.
Moving the whole shape take 20 sec. Save (14MB) 1sec. Open 10 sec.
Comment 11 Heiko Tietze 2016-06-21 14:37:12 UTC
So may the developers decide about this ticket. Back to NEW.
Comment 12 QA Administrators 2017-09-01 11:14:52 UTC Comment hidden (obsolete)
Comment 13 Roman Kuznetsov 2018-06-17 12:19:03 UTC
(In reply to Ferry Toth from comment #10)
> We are now 4 years later, so my processor improve to i7-3770 @ 3.4GHz.
> 
> Opening the file now takes 40 sec, moving after selecting everything on page
> 8 takes 35 sec.
> 
> I wouldn't want to close this as I think the attachments are being used as
> test case to check for regressions.
> 
> Also, even though the improvement has been substantial, there is probably
> more that could be done.
> 
> For instance, importing (not opening) page 8 of the PDF into Inkscape takes
> 20sec.
> Moving the whole shape take 20 sec. Save (14MB) 1sec. Open 10 sec.

I have bad news

in

Version: 6.1.0.0.beta2+ (x64)
Build ID: fe1a23b5c49c94410a604c8d4a6f50f43d575403
CPU threads: 4; OS: Windows 10.0; UI render: GL; 
TinderBox: Win-x86_64@42, Branch:libreoffice-6-1, Time: 2018-06-17_06:31:41
Locale: ru-RU (ru_RU); Calc: CL

Opening of PDF file from attach now takes 8 minutes!

My hardware: Intel Core-i5 7300HQ 2.5 GHz (4 core) and 6 Gb of memory

may be there was regression....