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
Created attachment 66916 [details] zip file containing original pdf
Created attachment 66918 [details] resulting drawing after conversion
Confirmed. Performance is extremely low here as well. My system specs are also lower than the one you listed.
Hi, everyone! I met the same problem (Slow move object in document with many objects)... Did anyone try to solve this problem? TY
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)?
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.
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
Migrating Whiteboard tags to Keywords: (perf)
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
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.
So may the developers decide about this ticket. Back to NEW.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.4.1 or 5.3.6 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170901
(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....
Dear Ferry Toth, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
*** Bug 114176 has been marked as a duplicate of this bug. ***
Dear Ferry Toth, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug