The file has >500k rows. Steps to reproduce. 1. Open file 2. Open standart filter - Calc freezes for a few minutes. 3. Specify a filter (for example, column 'A' = '888-001695' - Calc will freez forever
Created attachment 102199 [details] test file
Column A is a messed up with text and values. If you set all values to text in this column - your filter-operations will work OK. Apparently LibreOffice don't like different formats in the filter-column, and I don't know if this is considered as an error.
If it is not possible to improve filter' speed, Calc may show message of slow speed
Well that was a miserable bug to bibisect - but it's done. Confirmed Ubuntu 14.04 x64 LibreOffice 4.2.5 release Works fine in 4.1.x Marking as: New Major - can prevent high quality/professional work - it essentially is a full freeze that any user would just quit and lose data in the end High - regression Would be nice to know if this is only with csv files. Bibisect Below: 83a62c1c1e8e259144e489d9a1f42611eba063c3 is the first bad commit commit 83a62c1c1e8e259144e489d9a1f42611eba063c3 Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Thu Oct 17 14:30:14 2013 +0000 source-hash-022c54742e7997bf46a608f1ab0b500f2537f7f5 commit 022c54742e7997bf46a608f1ab0b500f2537f7f5 Author: Tor Lillqvist <tml@iki.fi> AuthorDate: Tue Jun 25 07:19:41 2013 +0300 Commit: Tor Lillqvist <tml@iki.fi> CommitDate: Tue Jun 25 07:19:41 2013 +0300 WaE: private field 'mrCells' is not used Change-Id: I0ab3fabb82c839f5194b0e20eb834dd86635a609 :100644 100644 4b10c5c8ddbedca0971e0839a8acc603792a447c 483b58760a06de929b32eafde25a67466c622502 M ccache.log :100644 100644 54c63dd94c275598f317bb54ddfdd27aaad5d8a1 fcfaf4eddaf5f8c7a66f90a052cbf2c7473cdc9b M commitmsg :100644 100644 e607019f9ceabe4513be6de63f5724c67ece57f9 3e023e83e964fd4b90d7bdf45eab489c7382956c M dev-install.log :100644 100644 2d16d57e331ca5fab2ec46ad12fe030528c544bb 47ead046b9af75e2384d8d8f51767edfa54d5dc8 M make.log :040000 040000 3aaab4081e7400904dc31731c74182db7e18493c 82a20807f2d069e8294cfa6e30778214a869a341 M opt # bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # good: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb git bisect good e02439a3d6297a1f5334fa558ddec5ef4212c574 # bad: [4850941efe43ae800be5c76e1102ab80ac2c085d] source-hash-980a6e552502f02f12c15bfb1c9f8e6269499f4b git bisect bad 4850941efe43ae800be5c76e1102ab80ac2c085d # skip: [a043626b542eb8314218d7439534dce2fc325304] source-hash-9379a922c07df3cdb7d567cc88dfaaa39ead3681 git bisect skip a043626b542eb8314218d7439534dce2fc325304 # skip: [aba65c3e4c0df07e4909aeefb758cdb688242bf6] source-hash-827524abfb4b577d08276fde40929a9adfb7ff1a git bisect skip aba65c3e4c0df07e4909aeefb758cdb688242bf6 # bad: [c81a8a0dcfc1ed095a80e4485c89dd0fcaf73f31] source-hash-c69ed33628ec0b7abf6296539cf280d6c4265930 git bisect bad c81a8a0dcfc1ed095a80e4485c89dd0fcaf73f31 # bad: [1d4980621741d3050a5fe61b247c157d769988f2] source-hash-89d01a7d8028ddb765e02c116d202a2435894217 git bisect bad 1d4980621741d3050a5fe61b247c157d769988f2 # bad: [ba096f438393091574da98fe7b8e6b05182a8971] source-hash-8499e78ca03c792f4fa2650e02b519094ba0baa8 git bisect bad ba096f438393091574da98fe7b8e6b05182a8971 # bad: [9daa289e178460daaafa4b3911031df5b8736218] source-hash-704292996a3731a61339b1a4a5c90c9403aa095f git bisect bad 9daa289e178460daaafa4b3911031df5b8736218 # good: [69bf614869471f46413fe1d2af5976b2e6d85084] source-hash-76dea8b2db906156e77f78738a68f932a15afd4b git bisect good 69bf614869471f46413fe1d2af5976b2e6d85084 # good: [502c05c771cd993b237febc2d8a20140fe589488] source-hash-462df4920ef50032c8f99a9db2ca34c9cc928657 git bisect good 502c05c771cd993b237febc2d8a20140fe589488 # bad: [567bfa79fb5ad4f9dfa05f0dea7666208d6129b2] source-hash-4d5fc661d37d03129b8054e494c03bed1933231d git bisect bad 567bfa79fb5ad4f9dfa05f0dea7666208d6129b2 # good: [7d878017eaa2fc1d2eab72689a5e453622d474a2] source-hash-b139f6fedfcf3cbed0eadeb007e2155b576413d2 git bisect good 7d878017eaa2fc1d2eab72689a5e453622d474a2 # bad: [83a62c1c1e8e259144e489d9a1f42611eba063c3] source-hash-022c54742e7997bf46a608f1ab0b500f2537f7f5 git bisect bad 83a62c1c1e8e259144e489d9a1f42611eba063c3 # first bad commit: [83a62c1c1e8e259144e489d9a1f42611eba063c3] source-hash-022c54742e7997bf46a608f1ab0b500f2537f7f5
I have never seen this bug in any files but csv.
The behaviour changed somewhere in the patch set c7bdee8dbd1cf260a8513a0d31b36f90daa70f1c..4c99a427ee4adaeddb2682c192384bad21d9d09b which begins as below. Building the commits individually doesn't seem to work, so a single commit can't easily be identified. commit c7bdee8dbd1cf260a8513a0d31b36f90daa70f1c Author: Kohei Yoshida <kohei.yoshida@gmail.com> Date: Wed May 22 20:27:24 2013 -0400 Define block types for string, edit text and formula cell elements. Also, remove the custom_ prefix from block names. Change-Id: If3dfdbdacc2d0113fa8d631bec7a914b51668115
Migrating Whiteboard tags to Keywords: (bibisected, perf)
So this file exposes about 3 performance problems. Selecting the whole range with content takes much more time than necessary in script type functions. Opening the dialog takes a long time in sorting all strings. Filtering takes a long time in stupid mdds access.
Created attachment 124683 [details] callgrind profiles for all three issues
** 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
Luboš Luňák committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/3e664b8f194392eb27aae953c0d33a8bdfd32982%5E%21 cache cell positions when opening standard filter in calc (tdf#80853) It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Luboš Luňák committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/ace16e500c92797bb47ad580cf535de0702137bd%5E%21 cache mdds access in ScTable::ValidQuery() (tdf#80853) It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Markus Mohrhard from comment #8) > So this file exposes about 3 performance problems. > > Selecting the whole range with content takes much more time than necessary > in script type functions. in Version: 6.3.0.0.alpha1+ Build ID: 9c7fac47aacb0877c7d212217089a680400c1377 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 it takes 4 seconds > > Opening the dialog takes a long time in sorting all strings. it takes 10 seconds > Filtering takes a long time in stupid mdds access. it takes 2 seconds Setting to VERIFIED @Luboš Luňák, thanks for fixing this issue!
I found LibreOffice hangs when I try to show the value dropdownlist from the dialog. I'll report it in a follow-up bug