|
Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
| Summary: | Calc is extremely slow when spreadsheet has many notes (comments) | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Calc | Reporter: | cianoz <luczani> | ||||
| Component: | editing | Assignee: | AOO issues mailing list <issues> | ||||
| Status: | CONFIRMED --- | QA Contact: | |||||
| Severity: | Trivial | ||||||
| Priority: | P3 | CC: | issues, knmc, newbie-02, orcmid, petko, rainerbielefeld_ooo_qa, rseitzde | ||||
| Version: | OOo 3.2 RC5 | Keywords: | oooqa | ||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Issue Type: | DEFECT | Latest Confirmation in: | 4.1.6 | ||||
| Developer Difficulty: | --- | ||||||
| Issue Depends on: | |||||||
| Issue Blocks: | 102716, 111037, 111390 | ||||||
| Attachments: |
|
||||||
Created attachment 67824 [details]
Calc spreadsheet with many notes that slow down operations
Looks like a duplicate of issue 102716 Taking this issue. See issue 111390 for an explanation. Will keep this issue open to not forget to test the attached document after fixing. I doubt that only WIN XP is affected, Issue 111037 has been reported for LINUX Reassigning to dr - "started" with owner "spreadsheet" doesn't make much sense. restore "started" state Removing Accepted state since this goes back to OO.o 3.2 and appears to be in limbo. completed the transition back to Uncomfirmed. This needs to be re-examined, and the condition characterized better. (I am not doubting that this might be a problem. We just have to take a fresh look.) *** Issue 128121 has been marked as a duplicate of this issue. *** retested this bug today with AOO416m1(Build:9790) - Rev. 1844436 2018-10-23 12:57 under win7 pro (x64) SP1, still an issue, pls. see add. comments in #128121, could somebody pls. recheck and set to confirmed, or new? *** Issue 128121 has been marked as a duplicate of this issue. *** hello @all, sorry for writing long, it is an old problem, in my opinion it is wrongly neglected, and it has - partly unnoticed / partly not attributed to the cause - considerable negative influence, i'd ask persons interested in the performance of calc to try to read to the end. (this info was originally written for #128121, as that is closed again as duplicate i provide an enhanced version here) (Sorry, I'm digressing, one general problem with the handling of bugs and some ideas for improvements (admins might push to a separate thread): i get a 'feeling' that the handling of bugs is somewhat 'suboptimal', old bugs tend to become 'old' and 'long', and collect some 'false positive' and 'no repro' comments, thus straying the focus of the readers, new bugs become closed as duplicates, users ignore old bugs because they should be resolved, new reports are pushed away from their attention as 'resolved - duplicate', the QA team has more and more work to just manage the bugs bureaucratically ... not an optimized process. 1. sort the comments list bottom up, newest comments on top of the list, thus focussing the attention of the reader to fresh info while he can still recheck all old info in the list below, 2. implement some sort of 'quality commenting' for the comments (in bugzilla), there is! some good info buried under plenty of questions and useless stuff, it should be pulled to attention somehow, 3. also sort the 'closing as duplicate' the other way around, fresh reports should be held open (they provide fresh information about the actual situation) while old reports can be closed, the info is still available, 4. do 3. at least when the discussion in the old thread entered an 'unproductive state') back to the topic: AOO and LO bear a long history of issues / bugs / comments / complaints regarding poor performance when using too many notes / comments in a sheet or file. see below list of 6 issues and retests today, still an issue, happy: i'm not alone, sad: something affecting the fun to work with OO and LO in a massive negative way is 'still in' after *10* years, alarming (me): work on the issue is hindered by the procedures described above under digression, apologize: i know this post will be 'too long' and little compatible with the 'local forms of handling' ... after ten years without significant progress and plenty attempts - of others - to handle the issue with short comments in accordance with the 'rules' ... i feel free to try another way ... it may fail, but that would not be a step backwards behind the lack of progress so far, and simply continue like yet would - probably - not bring any progress either, ecological: just an assumption: 8 billion people worldwide, 4 billions awake, 1 billion using computers, 10% (100 millions) using spreadsheets, 20% (20 millions) LO or OO (maybe the bug is in e$x$cel as well), 50% (10 millions) using comments, theese wasting 20 watt of cpu-power for comments ... the impact in wasted energy is about 200 Megawatt!, about one sixth of an usual big nuclear power plant :-(, with german average prices 60.000 EUR per hour? (since ten years?) !!! ... besides massive wasting time of users ... !!! !!! ... and straying big frustration on those affected by the problem but without skills and time to analyze ... !!! satirized: wasting 2 seconds on every click of a normal user with 10000 clicks per day (~20 per minute) will waste 20.000.000.000 seconds of mankind lifetime per day, thats every 6 month the impact of '911'! (ok, the time wasted on security checks at airports is somewhat 'more effective') brutality: what i *absolutely dislike* abut that bug (deepl'ed): it creeps in unnoticed, gradually increases with the amount of data until users notice a problem, but then there's no clue what the cause is, they're wasting time on research, or slow work, or switch to another program. And even before using comments, there was no hint: 'Beware!, too many comments can drastically slow down your system!'. history: i had a big issue with e$x$cel in the past, it killed a company, a partnership, the work of 6 years ... the symptoms had been the same, increasing slowness with no unterstandable reason ... may be it was the same issue ... ??? history 2: Honour to whom honour is due: Issue #102716 - Calc is very slow for some operations (with many notes), should be held as the original report, this one is just another duplicate, festivity: #102716 is reported '2009-06-12 13:20 UTC by sukender', we can hold 10th anniversary wednesday next week, prepare yourselves for a [big celebration / great memorial service], technical: despite that the handling of a comment shouldn't be much more complex than the handling of a cell (added positon on the screen, substracted formulae, calculation and referencing) it obviously is! in current implementations. there is some useful technical info in: - https://bz.apache.org/ooo/show_bug.cgi?id=102716#c0 - https://bz.apache.org/ooo/show_bug.cgi?id=102716#c9 - https://bz.apache.org/ooo/show_bug.cgi?id=111390#c4 - https://bz.apache.org/ooo/show_bug.cgi?id=111390#c8 - https://bz.apache.org/ooo/show_bug.cgi?id=102716#c9 strategy: whilest not able to solve the problem i'd suggest: - !!!some sort of warning to the users in orer to prevent more and more of them stepping into this trap!!!, - some workaround as suggested somewhere 'implement a switch to use flat comments instead of the performance killing prettyfied M$ overhead' or similar, - a somewhat 'deeper' information why the 'current implementation' is neccessarily ressource wasting, loops? recursions? one-way-references? search instead of indexed access? how is the workflow? (did someone organize first to prepare the display of all comments and then to hide them from visibility?) how is the data structure? (imho: screen is painted, mouse is moved, staying in a cell: do nothing, leaving a cell: triggering repaint where the comment must no longer be shown (delete comment representation from the comment overlay?), entering a cell: check if commented, select comment, select position to show, draw box, display ... that's not much work for a modern machine.) - some thoughts about an analysis of the 'current implementation' and if improvements are possible, may be also M$ would be interested? - crowdfunding to engage a paid programmer strategy 2: work together with the LO community, they have the same issue, funnily in the latest dev. releases reduced to occur after the first autosave only, thus mistakenly ignored by testers and developers, but may be they are close to a solution (just left problems with the representation / search / check in autosave info)? activity: searched again today (yesterday) and found three the same issues: Issue 109276 - Calc is extremely slow when spreadsheet has many notes (comments) reported *2010*-02-15 09:20 UTC by cianoz status today: Status: UNCONFIRMED tested today: hard work for system to copy content, errors like 'no space to copy here', lightning fast after stripping comments, thus: still issue, Issue 117348 - freeze or out of memory , when paste a lot of cells with comment. reported *2011*-03-12 04:12 UTC by paz_ohhashi status today: Status: UNCONFIRMED tested today: Issue 117348: high load and delay and 'not responding' on copying the row with comments, had to kill the task, thus: still issue, Issue 127715 - Changes in spreadsheet with many notes (comments) extremely slow reported 2018-02-26 12:26 UTC by orion status today: Status: UNCONFIRMED tested today: visible delays alredy with very small amounts of data and comments, thus: still issue, and even more domino-like after noticing that comments are called 'notes' as well: Issue 102716 - Calc is very slow for some operations (with many notes) reported *2009*-06-12 13:20 UTC by sukender this is at least Status: CONFIRMED tested today: deleting a line, heavy load and 'not responding', thus: still issue, Issue 111390 - OOo Calc 3.0.1 and higher --> Notes bug reported: *2010*-05-05 09:12 UTC by jsteenks despite being confirmed in: https://bz.apache.org/ooo/show_bug.cgi?id=111390#c2 status today: Status: CLOSED *IRREPRODUCIBLE* but some useful info in: https://bz.apache.org/ooo/show_bug.cgi?id=111390#c4 tested today: small sheet, few comments, first no problem, maybe i didn't get the functionality of the sheet, unfolded invisible rows and cols, added 75k cells with '1' in it commented '1', dead, sorry, finished and came back to live after ~10 minutes, 13 % of cpu-load on hovering with the mouse over the sheet, thus: still issue, Issue 111037 - An example of XLS/ODS file which slows down OOo reported: *2010*-04-21 11:10 UTC by hiddenman this is at least Status: CONFIRMED tested today: visible delays, graphics fu**ed after deleting one column, 15 times faster after strippung comments, thus: still issue, i'd stop listing here, my impression: there is a 'big bug', and one will easily find plenty other complaints about performance which did not get the boildown to the root 'comments' or 'notes', but which do rely on theese effects and you'll see it once you test 'em against this issue. so please believe me: there is an issue!, this bug is! a duplicate of plenty others, as they are still unresolved it's an appeal to take this issue seriously ... ok, thats what i could do to pull attention to this issue, hope it helps ... reg. b. *** Issue 127715 has been marked as a duplicate of this issue. *** this bug is 9,5 years old!, it ist very easy to reproduce, it has at least 2 duplicates in the bugzilla, and no one has taken a heart to set it to 'new'? no developer will care for it while 'unconfirmed', pleas, please, please ... somebody with the power to do so - mine isn't, just a newbie - set it to 'new', it is! a bug, and it needs attention ... tia, b. Ok I set it to confirmed. |
If you have a large spreadsheet with a great number of comments ("notes") every operation that involves moving or copying the notes will dramatically slow down the program. The greater the number of comments the longer OO takes to perform operations. For example open the attached spreadsheet, that have a lot of comments inserted, and try to apply a filter on any column. It takes a very long time to apply the filter. Another example on the same file, but even more heavy: select the entire sheet content then cut and paste in place. OO Calc will freeze and you have to terminate it (maybe it will paste the content sooner or later but i tried to wait for minutes) Select the entire sheet then remove/delete all notes and try any of the previous operations: filter is applied in a second and cut and paste takes only a few seconds. This is quite a serious problem for those (like us) that use big spreadsheets in a business environment, where filters are used as an habitual tool for daily work. Hope this will be fixed in the next 3.2.1