Build ID: 7f476fea47f06a7f8cc961dd4f6595a524346fa5
TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2014-12-27_23:36:28
Steps to reproduce:
- Create a new calc document
- Write '1' into A1 cell. Create a comment in cell A1 such as "test comment".
- Copy this cell into clipboard (ctrl + C)
- Select area A1:A3200
100% CPU freeze for few minutes, then I killed soffice
Cells copied into area A2:A3200
I can not reproduce with LO 4.3.5, win7 -> regression
Ubuntu 14.04 x 64
LibreOffice 4.4 beta 2 - confirmed
LibreOffice 184.108.40.206 - no problem
Major - crash/hard freeze
Highest - regression + crash
Created attachment 111978 [details]
As you can see. Bug not reproducible for me with 2Gb RAM
LO 4.4 beta 2
Ubuntu 14.10 64-bit
Are you sure that's beta 2? It says alpha2+.
For me I have 4GB of RAM and hitting this issue consistently every time on multiple systems.
Regression does not appear in latest version of bibisect-44.tar.xz and must be younger.
I couldn't reproduce this in 4.5 from the 45 bibisect tree around the time of the build in comment 0, or on current 4.5 master, or in 220.127.116.11. The paste finished in a few seconds each time
(I do have a lot of memory - 16G and 24G, but I didn't see any signs of a particular spike in usage during the paste)
I can't reproduce this in 18.104.22.168 - takes only few seconds. Do you really try with just 3200 cells? not 32000?
Pasting was fixed as part of bug 76324.
If it's really reproducible, cachegrind trace would help:
Get it with smaller number of cells, maybe 500, so it eventually finishes.
I can not reproduce with Version: 22.214.171.124.alpha1+
Build ID: 51d16cc69d8ad9065f61d108ea25d6a025a2e228
TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2015-05-17_03:27:43
Migrating Whiteboard tags to Keywords: (bibisected)
sorry for bad news,
this bug isn't solved yet, at least not in total,
#76324 is still in state 'new',
there is still a performance issue with files - (files not sheets, the comments on not displayed sheets seem to affect performance in the shown sheet as well),
may be it's reduced to occur only after the first autosave, thus hidden from a fast check by testers,
modern machines can bear more but limited amount of comments, try doubling the number of cells with comments copied until you see issues, strip the comments from the sheet, double data cells again, and you see it's lightning fast compared to half the cells but with comments.
thus: poor performance, wasting time and energy.
Even if bug 76324 is open, it doesn't mean we have to reopen all similar bugs.
According to comment 8, this particular case is not reproducible in 5.5
Please, do not reopen it, specially after more than 4 years since it was closed.
@ xisco: imho it's not qualifying to close a bug just for one (false?) positive comment, (on a special machine, special OS, few comments, and not waited for autosave?),
having a performance issue with too many comments / notes is not! solved if one user is happy with it and overlooked the problem ...
i want to give help to identify the problem and get something done on it, for that purpose i thought - and still think - it's productive to shed light on all aspects of the issue,
and perhaps to 'undig' some info from buried threads ...
just an frustrated helpless attempt ...
is it possible to close the other bugs and produce one fresh and collect all still visible and helpful info in that?
i'd like that ...
(In reply to b. from comment #12)
> is it possible to close the other bugs and produce one fresh and collect
> all still visible and helpful info in that?
> i'd like that ...
Which other bugs ?