Summary: | EDITING, CRASH: performance problem regarding comments significantly mitigated in ver. 6.2.7.1 under windows but persistent in linux version | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | b. <newbie-02> |
Component: | Calc | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | aron.budea, serval2412, xiscofauli |
Priority: | medium | ||
Version: | 6.2.7.1 release | ||
Hardware: | All | ||
OS: | All | ||
See Also: | https://bugs.documentfoundation.org/show_bug.cgi?id=76324 | ||
Whiteboard: | |||
Crash report or crash signature: | Regression By: |
Description
b.
2019-09-25 11:59:36 UTC
Considering the time you spent on it, I think you might be interested in building LO from sources to retrieve more information or for coding? (see https://wiki.documentfoundation.org/Development) At least, a Flamegraph may help to find bottleneck. About Linux/Windows difference, it may be related to renderings. You can try different renderings on Linux: gtk3, kf5 (= kde5), gen. for example, on console, type: SAL_USE_VCLPLUGIN=gen;soffice --calc or SAL_USE_VCLPLUGIN=kf5;soffice --calc For Linux, the pb is in sc/source/ui/Accessibility/AccessibleDocument.cxx. Indeed, when using "gen" rendering, it's far more faster than "gtk3". "gen" rendering doesn't use accessibility part. @Julien Nabet, hello, and thanks for your help, i tried the different rendering machines, they do! have an impact on performance, but i measured times between 1:15 and 2:30 minutes for the paste of a cell with a comment to 2.500 empty cells, that's very little compared to the mentioned win version completing this task in less than 5 seconds, thus it's not touching the core of the problem. i'd like you - and others - to retest my steps and report wether they find 'normal' behaviour or disturbing delays. btw.: also with the 'best yet seen' version, 6.2.7.1 win x-64, filling one column in total with commented cells leeds to 'not responding' and not finishing the task, requiring an external kill. reg. coding and flamegraphs, - i tried installing a development environment some time ago, was stuck in an incompatibility between some 32 vs. 64 bit components, and will retry once i have more time for that, - i doubt if it's a good idea to let newbies reprogram difficult code, i'm talented in pinpointing errors, i'm not motivated to replace them with better errors from me, - i didn't work full time on this issue, i'm very well stretched by my normal job, - thus i'd like help from others with: -- retest the issue, just to rule out me, my machine, my system or my configuration being drunk or bad, (it's very easy, copy one commented cell to a full column, compare with that the copy of an uncommented cell works on the fly) -- once confirmed i'd like people experienced with coding, profiling and flamegraphs to take over and care for that issue, imho. that's the idea behind a community, people combining their special talents and knowledge to improve the product and learn fom each other. reg. b. When I saw the time it takes just when copying the cell with comment on a large range, I stopped here and launched Flamegraph. Noel found the bottleneck, I think it's not the only one but we must tackle it first. I'm waiting for his feedback because not sure about what he means. Concerning dev contribution: About build problems, you can send a message on LO Dev forum or ping LO dev IRC. About buggy patches, don't be afraid to give a try since they're reviewed by devs on gerrit. Now it was just a suggestion, no obligation of course! :-) @Julien Nabet thank you, it's a big relief for me to read that someone is taking care of this and making progress, i tried to install 'dev' (this time on linux, former try was windows), the video tutorial was helpful and only Kerberos was missing, my system does the first 'make', it takes a while ... a long while ... i would be happy if you could post the flamegraph, it could help more people to take the problem seriously, and give me an idea what i was fighting against ... if you have the 'power' please set the bug to 'new', thank you very much, b. b.: Flamegraph is here: https://bugs.documentfoundation.org/show_bug.cgi?id=76324#c75 Xisco: should we close tdf#76324 because there's already a long history and keep on this one? (In reply to Julien Nabet from comment #6) > b.: Flamegraph is here: > https://bugs.documentfoundation.org/show_bug.cgi?id=76324#c75 > > Xisco: should we close tdf#76324 because there's already a long history and > keep on this one? well, same story here. the first comment is 200 lines long, very inconvenient for reading... Anyway, I don't know why this issue got back to UNCONFIRMED. it's a clear duplicate of bug 76324 *** This bug has been marked as a duplicate of bug 76324 *** @Xisco: did you read this? 'this bug refers to that old bug, it is not! a duplicate of it as it describes a significantly changed behaviour, thus pls. take it serious instead pulling it out of sight as duplicate' sorry, my comments are long, but 54 (plus some whitespace) is not 200, i feel it's neccessary to use some more words when trying to get attention to a bug: - whose root ist many years old, - and which is not / only partly solved after hundreds of comments with few words which are convenient to read ... and: a bug nearly resolved in win-ver while still present in lin-ver must not! be the same as one affecting both versions, not finally tested, seems win 6.4 is bad again, pls. also take https://bugs.documentfoundation.org/show_bug.cgi?id=125619#c9 and previous from 125619 into account reg. b. |