Created attachment 126061 [details] Testprogram and Screenshot We are using Java Uno API to open documents from other applications with LO Calc. Since LO 4.4 this process takes a long time (from LO 4.4 up to LO 5.1.4). LO 4.3.7 is the last "normal" working version. LO 4.3.7 - 33821 Milliseconds LO 5.0.6 - 128793 Milliseconds LO 5.1.4 - 147996 Milliseconds (Attachment: cmd.jpg) Steps to reproduce: 1) copy the file (attachment: Libreofficetest.jar) into c:\temp 2) open a command prompt window 3) goto c:\temp and paste: java -cp Libreofficetest.jar;"C:\Program Files (x86)\LibreOffice 4\URE\java\java_uno.jar";"C:\Program Files (x86)\LibreOffice 4\URE\java\juh.jar";"C:\Program Files (x86)\LibreOffice 4\URE\java\jurt.jar";"C:\Program Files (x86)\LibreOffice 4\program\classes\unoil.jar";"C:\Program Files (x86)\LibreOffice 4\URE\java\unoloader.jar";"C:\Program Files (x86)\LibreOffice 4\URE\java\ridl.jar" test/TestLibreOffice 4) hit enter (LO 4.3.7) or java -cp Libreofficetest.jar;"C:\Program Files (x86)\LibreOffice 5\program\classes\java_uno.jar";"C:\Program Files (x86)\LibreOffice 5\program\classes\juh.jar";"C:\Program Files (x86)\LibreOffice 5\program\classes\jurt.jar";"C:\Program Files (x86)\LibreOffice 5\program\classes\unoil.jar";"C:\Program Files (x86)\LibreOffice 5\program\classes\unoloader.jar";"C:\Program Files (x86)\LibreOffice 5\program\classes\ridl.jar" test/TestLibreOffice (Lo 5.0.6 and 5.1.4) 5) Don't close LO! 6) you should see in the cmd-window: Time to fill Spreadsheet: XXXXX milliseconds Code "Libreofficetest.jar": package test; import java.util.Date; import com.sun.star.beans.PropertyValue; import com.sun.star.comp.helper.Bootstrap; import com.sun.star.frame.XComponentLoader; import com.sun.star.lang.XComponent; import com.sun.star.lang.XMultiComponentFactory; import com.sun.star.sheet.XSpreadsheet; import com.sun.star.sheet.XSpreadsheetDocument; import com.sun.star.table.XCell; import com.sun.star.text.XText; import com.sun.star.uno.UnoRuntime; import com.sun.star.uno.XComponentContext; public class TestLibreOffice { public static void main(String[] args) { try { // Connect to Libreoffice and create a new Spreadsheet. XComponentContext xContext = Bootstrap.bootstrap(); XMultiComponentFactory xMCF = xContext.getServiceManager(); Object oDesktop = xMCF.createInstanceWithContext("com.sun.star.frame.Desktop", xContext); // query the desktop object for the XComponentLoader XComponentLoader xCLoader = (XComponentLoader) UnoRuntime.queryInterface(XComponentLoader.class, oDesktop); PropertyValue[] lProperties = new PropertyValue[2]; XComponent xComp = xCLoader.loadComponentFromURL("private:factory/scalc", "_blank", 0, lProperties); XSpreadsheetDocument document = (XSpreadsheetDocument) UnoRuntime.queryInterface(XSpreadsheetDocument.class, xComp); // Deactivate Recalculation and Screenupdates to improve // performance. com.sun.star.sheet.XCalculatable xCalculateable = (com.sun.star.sheet.XCalculatable) UnoRuntime .queryInterface(com.sun.star.sheet.XCalculatable.class, document); xCalculateable.enableAutomaticCalculation(false); com.sun.star.frame.XModel xModel = (com.sun.star.frame.XModel) UnoRuntime .queryInterface(com.sun.star.frame.XModel.class, document); xModel.lockControllers(); com.sun.star.document.XActionLockable xActionLockable = (com.sun.star.document.XActionLockable) UnoRuntime .queryInterface(com.sun.star.document.XActionLockable.class, document); xActionLockable.addActionLock(); Object obj = document.getSheets().getByName(document.getSheets().getElementNames()[0]); XSpreadsheet sheet = UnoRuntime.queryInterface(XSpreadsheet.class, obj); long time = new Date().getTime(); // Fille the Spreadsheet with some values in a loop. for (int row = 1; row < 1000; row++) { for (int col = 1; col < 20; col++) { XCell cell = sheet.getCellByPosition(col, row); XText xCellText = (XText) UnoRuntime.queryInterface(XText.class, cell); xCellText.insertString(xCellText.createTextCursor(), new Integer(row + col).toString(), false); } } // Report how long it took to fill the Spreadsheet. System.out.println("Time to fill Spreadsheet:" + (new Date().getTime() - time) + " milliseconds"); // Reenable Autoupdates xActionLockable.removeActionLock(); xModel.unlockControllers(); xCalculateable.enableAutomaticCalculation(true); System.exit(0); } catch (Exception e) { e.printStackTrace(); } } } LibreOffice 5.0.6, Win 7 PRO SP1 64 Bit, German, different Hardware and different Users java version "1.8.0_91" Java(TM) SE Runtime Environment (build 1.8.0_91-b14) Java HotSpot(TM) Client VM (build 25.91-b14, mixed mode, sharing)
Time to fill Spreadsheet:269244 milliseconds Win 7 Pro 64-bit, Version: 5.1.3.2 (x64) Build ID: 644e4637d1d8544fd9f56425bd6cec110e49301b CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; Locale: fi-FI (fi_FI)
I can confirm the problem. Since LO 4.4 the performance of Java UNO API in calc is very weak compared to LO 4.3. I have tested all Versions till 5.1.4, but every version sincd 4.4 shows the same performance problem. This is a major problem for us and prevent us from upgrading 4.3 to a newer version in our company.
Bug still present in LO 5.2.2.2.
** 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 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
I was going to try and bibisect this, but under cygwin I can't get it to work. Here is my command: '/cygdrive/c/Program Files (x86)/Java/jre1.8.0_161/bin/java' -cp /cygdrive/c/Temp/LO/Libreofficetest.jar:instdir/URE/java/java_uno.jar:instdir/URE/java/juh.jar:instdir/URE/java/jurt.jar:instdir/program/classes/unoil.jar:instdir/URE/java/unoloader.jar:instdir/URE/java/ridl.jar test/TestLibreOffice It says: Error: Could not find or load main class test.TestLibreOffice I tried also copying the Libreofficetest.jar to where I am executing it, but no help. I am executing it in the bibisect directory. How could I get it to work? Anyway, I repro already in 4.4.7.2 and still repro in master.
Solved my launch problem thanks to David Ostrovsky pointing out an answer on SO: CP="C:\Temp\LO\Libreofficetest.jar;C:\Program Files (x86)\LibreOffice_43beta1\URE\java\java_uno.jar;C:\Program Files (x86)\LibreOffice_43beta1\URE\java\juh.jar;C:\Program Files (x86)\LibreOffice_43beta1\URE\java\jurt.jar;C:\Program Files (x86)\LibreOffice_43beta1\program\classes\unoil.jar;C:\Program Files (x86)\LibreOffice_43beta1\URE\java\unoloader.jar;C:\Program Files (x86)\LibreOffice_43beta1\URE\java\ridl.jar" '/cygdrive/c/Program Files (x86)/Java/jre1.8.0_161/bin/java' -classpath "$(cygpath -pw "$CP")" test.TestLibreOffice
Ok, so I observed there was a doubling of the original time and then a quadrupling of the original time in the bibisect_win_44 repository. When I told git the quadrupling was bad, I got a result that was clearly wrong (commit removing one line with no relevance). When I told git the doubling was bad, I got this sweeping commit from Noel: https://cgit.freedesktop.org/libreoffice/core/commit/?id=5bce32904091ffe28884fd5c0f4801ee82bad101 That looks like something that might have lead to the slowdown, but at the same time it feels outrageous to demand Noel to "fix" this. After all, it is "convert home-grown run-time type information to normal C++ RTTI". We would have to demand Noel to come up with an improvement that is wholly separate to his 2014 change. Adding Noel to CC in any case to comment. The win_44 repo has an interval of 8 source commits and Noel's commit seems the likely one from the range of https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=5bce32904091ffe28884fd5c0f4801ee82bad101...ba0498a696423036360f51b15f9e21f180c7dedf This is not Windows-only as I have a similar time difference between Linux master and 3.6. Here is how I launched with 3.6: java -cp /home/user/libobugs/LO/Libreofficetest.jar:/home/user/liboold/LibO_3.6.7.2_Linux_x86-64_install-rpm_en-US/RPMS/install/opt/libreoffice3.6/ure/share/java/java_uno.jar:/home/user/liboold/LibO_3.6.7.2_Linux_x86-64_install-rpm_en-US/RPMS/install/opt/libreoffice3.6/ure/share/java/juh.jar:/home/user/liboold/LibO_3.6.7.2_Linux_x86-64_install-rpm_en-US/RPMS/install/opt/libreoffice3.6/ure/share/java/jurt.jar:/home/user/liboold/LibO_3.6.7.2_Linux_x86-64_install-rpm_en-US/RPMS/install/opt/libreoffice3.6/program/classes/unoil.jar:/home/user/liboold/LibO_3.6.7.2_Linux_x86-64_install-rpm_en-US/RPMS/install/opt/libreoffice3.6/ure/share/java/unoloader.jar:/home/user/liboold/LibO_3.6.7.2_Linux_x86-64_install-rpm_en-US/RPMS/install/opt/libreoffice3.6/ure/share/java/ridl.jar test.TestLibreOffice
Noel Grandin committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=06f86d544c8017c2e736bc77db27dd623853770b tdf#100756 slowdown in manipulating spreadsheet via UNO It will be available in 6.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel Grandin committed a patch related to this issue. It has been pushed to "libreoffice-6-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c520c7de690b0de826467758bfd9313b287e1956&h=libreoffice-6-1 tdf#100756 slowdown in manipulating spreadsheet via UNO It will be available in 6.1.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.