Created attachment 56652 [details] spreadsheet containing a large number of timestamp values Hi, please, see the joined example LibO 3.5.0 rc3 / Windows 7 (tested on 3.4.5: no problem)
Hi, Doesn't crash on Mac OSX 10.6.8, but it does take 40 seconds to display the filter dialogue. Alex
To compare, in 3.3.4, on Mac OSX 10.6.8, the filter dialogue appears almost instantaneously on the same file - performance regression. Alex
(In reply to comment #2) > To compare, in 3.3.4, on Mac OSX 10.6.8, the filter dialogue appears almost > instantaneously on the same file - performance regression. > > Alex Compared also with 3.4.5, filter dialog appears almost instantaneously. Alex
Confirming the worse performance comparing to LO 3.4.5. In fact Calc does not freeze, it works hard : CPU 100% on one core until autofilter popup is shown. Kohei: it seems it is for you. :-) Please, feel free to reassign if you can't handle this bug report. Best regards. JBF
Changing platform and OS to All because I reproduce the problem on Ubuntu too. Best regards. JBF
Had a wuick look into this one and I think we need to move SvListView from tools::Table to boost::ptr_map to solve this problem.
Markus Mohrhard committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=1c9f0a6ddb48f7b6d62670901e117b25a0e59713 move SvListView from Table to ptr_map, related fdo#45679
This was only a first step. There are some more problems here. Filling the dialog with data is in O(n^2) and not in O(n). The same problem is know for the Manage Names Dialog.
I'll take this one. As discussed with Kohei we have several solutions to the problem. I will for now implement the init solution. This means that I'll add a init method taking a vector<rtl::OUString> to get initializing the dialog into O(n). (Initializing the vector will still be in O(n^2) because we need to prevent duplicates. This should still be way faster than the old algorithm which needed to sync a lot of data after adding each entry.
It was even much more easy than I ever imagined. By luck I stumbled over SetUpdateMode which kills the O(n^2) algorithm in the dialog. Implemented the same for the range names dialogs. I think we will see those fixes in 3.5.3 I think someone else had the same problem but did not document the use of the method.
Markus Mohrhard committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=bd20b48795df0e23ac76d516d56366250157515f prevent update during init in new autofilter dlg, fdo#45679
Markus Mohrhard committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=cb2c9eb114d3a76096fd404d733f86702246b60e prevent update during init in name dlgs, related fdo#45679
Tested in master (LibreOffice 3.6.0alpha0+ Build ID: 08ba87c-49d3d39-e67b1bf-879ce36-638d9c). Very impressive ! :-) Best regards. JBF
Markus Mohrhard committed a patch related to this issue. It has been pushed to "libreoffice-3-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=801c5d5b88454f659a08d9a4940b90499bec9584&g=libreoffice-3-5 prevent update during init in new autofilter dlg, fdo#45679 It will be available in LibreOffice 3.5.3.
Markus Mohrhard committed a patch related to this issue. It has been pushed to "libreoffice-3-5-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=208d129b7214eaedfc3dd22f78330c099d680dd3&g=libreoffice-3-5-2 prevent update during init in new autofilter dlg, fdo#45679 It will be available already in LibreOffice 3.5.2.