Bug 123371 - Macros are extremely slow in 6.2
Summary: Macros are extremely slow in 6.2
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
6.2.0.3 release
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-02-11 19:37 UTC by Alan
Modified: 2019-03-28 17:55 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
example spreadsheet (62.80 KB, application/vnd.oasis.opendocument.spreadsheet)
2019-02-11 19:38 UTC, Alan
Details
Code for spreadsheet (7.63 KB, text/plain)
2019-02-12 00:53 UTC, Alan
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alan 2019-02-11 19:37:51 UTC
Description:
A macro that was running very fast in versions 6.0 and prior runs extremely slow in version 6.2.0.3. The macro copies certain areas from one sheet to another.
From the attached spreadsheet, pick a county from the black dropdown in cell G4 then click on the update button.
Will provide more info on request

Steps to Reproduce:
1.Open spreadsheet
2.Pick county from dropdown
3.Click on the update button

Actual Results:
After clicking on the 'update summary sheet' button the summary sheet takes a long time to update

Expected Results:
After clicking on the 'update summary sheet' button the summary sheet should take a very short time to update


Reproducible: Always


User Profile Reset: No



Additional Info:
Affected version:
Version: 6.2.0.3
Build ID: 98c6a8a1c6c7b144ce3cc729e34964b47ce25d62
CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: kde5; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: CL

Working version:
Version: 6.0.7.3
Build ID: dc89aa7a9eabfd848af146d5086077aeed2ae4a5
CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: kde4; 
Locale: en-US (en_US.UTF-8); Calc: CL

Both are installed in /opt via downloads from https://www.libreoffice.org/
Comment 1 Alan 2019-02-11 19:38:54 UTC
Created attachment 149168 [details]
example spreadsheet
Comment 2 Drew Jensen 2019-02-11 20:47:10 UTC
Trying to confirm the issue and I'm having a problem with the macro code:

CellVal=GetCellContentsString(0,"G4")

Throws and error of function not found? 

Is there another local library which you might of overlooked?
Comment 3 Alan 2019-02-12 00:52:43 UTC
I'm sorry about that. I missed 2 functions I wrote at the end. Should have tested that it worked first.
I've uploaded the complete set of code I use for that spreadsheet.
Comment 4 Alan 2019-02-12 00:53:11 UTC
Created attachment 149176 [details]
Code for spreadsheet
Comment 5 Xisco Faulí 2019-02-12 13:58:38 UTC
I can't reproduce it in

Version: 6.3.0.0.alpha0+
Build ID: a8f21e120b1073d7019d41e85cc9a15104ed5c93
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US
Calc: threaded

To be certain the reported issue is not
related to corruption in the user profile, could you please reset your
Libreoffice profile ( https://wiki.documentfoundation.org/UserProfile ) and
re-test?

I have set the bug's status to 'NEEDINFO'. Please change it back to
'UNCONFIRMED' if the issue is still present
Comment 6 Drew Jensen 2019-02-12 14:58:58 UTC
(In reply to Alan from comment #4)
> Created attachment 149176 [details]
> Code for spreadsheet

Thanks - that did it.

1st - I agree you should check you user directory as a good first step. 

2nd - there does seem to be a difference between 6.0 and the later versions but the  difference appears small. Nothing close to the 10 seconds mentioned in the social media post. This morning though I ran the macros from the UI so don't have actual time values for any difference. What I'll do now is run this again but from a test harness script to get precise timings. (also will update the different versions to the latest builds before the test).

3rd - I noticed that there is a third party library in use when the macro to clear the copied sheets is used, which of course fails here as I don't have access to that third party tool. I wonder if maybe that is playing in somehow here (though unlikely perhaps).
Comment 7 Alan 2019-02-12 18:33:09 UTC
Xisco Faulí,
I played around with all the options that reset the user profile with the same results. I then deleted my entire profile folder so when I restarted libreoffice would create a default profile. Same results although it may be a second quicker, I didn't actually time it before.
I tested it in 6.1.5 from a fresh download and the issue is not there. The macro completes quickly. I tested with a newly generated profile and my current profile. No perceivable difference so it appears to be some change from 6.1 to 6.2 is causing this.
I see that you tested it in a gtk environment. Do you have access to a kde environment? I'm running Kubuntu 18.04.2 (KDE 5.44.0 / Plasma 5.12.7). Maybe it has to do with the switch from kde4 to kde5?


Drew Jensen,
The only third party tool I use is MRI but that is all commented out. Do you mean the 'Clear Everything' buttons? I wrote that code and keep it under the Standard dialog instead of the spreadsheet itself because that's where I keep all the code. I didn't include that code in this bug report since it isn't relevant in this case. If it isn't the clear buttons' code what sub is it in?
Comment 8 raal 2019-02-12 21:40:58 UTC
Tested with Version: 6.3.0.0.alpha0+
Build ID: c7ad7849d54fd3dad67e7779102f65b8b2f04881
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
and macro is quick -  1 second.
Comment 9 Xisco Faulí 2019-03-21 12:00:05 UTC
Hello Alan,
LibreOffice 6.2.2.2 is going to be released today, could you please try again
with this version to see if the problem has been resolved meanwhile? Thanks in
advance
Comment 10 Alan 2019-03-28 17:54:06 UTC
Installed 6.2.2.2 from Ubuntu's repro. The issue is gone, macros take the right amount of time. Bug closed for me.
Thanks!
Comment 11 Xisco Faulí 2019-03-28 17:55:48 UTC
(In reply to Alan from comment #10)
> Installed 6.2.2.2 from Ubuntu's repro. The issue is gone, macros take the
> right amount of time. Bug closed for me.
> Thanks!

Thanks for retesting with the latest version.
Setting to RESOLVED WORKSFORME as the commit fixing this issue hasn't been identified.