Issue 99371 - Copy-paste of columns very slow
Summary: Copy-paste of columns very slow
Alias: None
Product: Calc
Classification: Application
Component: editing (show other issues)
Version: OOo 3.0
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Keywords: performance
: 110446 (view as issue list)
Depends on:
Reported: 2009-02-18 11:58 UTC by gonedelyon
Modified: 2017-05-20 11:11 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description gonedelyon 2009-02-18 11:58:27 UTC

Copying and pasting columns is a real pain in the neck. I get the spinning ball as soon as I copy, and it can takes minutes before the application 
responds again.
The processor load probably increases dramatically, as the ventilator quickly starts, and the Mac is nearly frozen: one cannot switch to another 
The amount of data is not relevant: it happens even with a few filled cells. But copying and pasting large amount of data or several columns crashes 

Mac OS X 10.4.11
OpenOffice 3.0.0 [300m11(Build.9299)]


Best regards,

Comment 1 ooo 2009-02-25 18:56:46 UTC
@pl: any known problems with Mac clipboard performance? What could cause this?
Comment 2 gonedelyon 2009-02-25 19:12:36 UTC
FYI, I forgot to mention it only happens with columns, not with lines.


Comment 3 philipp.lohmann 2009-02-26 09:43:51 UTC
I don't see the performance issue (that is however on mac os 10.5), but I get
the crash in 3.0 (OOO300m9), too. However it does not seem to happen in
DEV300m40, so it seems to be fixed by now.
Comment 4 philipp.lohmann 2009-02-26 09:52:14 UTC
One thing I notice however that might be related: at termination if the last
thing in the clipboard was a column, calc seems to flush the clipboard and write
a large bitmap (which takes some time). Also it crashes afterward in a copy
request from the system clipboard, probably because the transferable the
document is already halfway gone ?

I will have a further look at this.
Comment 5 philipp.lohmann 2009-09-05 15:45:59 UTC
Comment 6 philipp.lohmann 2010-01-20 14:45:13 UTC
As far as I can see, the reason is indeed the very large bitmap transported -
and this is not a Mac only problem. That should be limited to a sensible size I

nn: please take over
Comment 7 philipp.lohmann 2010-08-30 17:25:59 UTC
*** Issue 110446 has been marked as a duplicate of this issue. ***
Comment 8 philipp.lohmann 2010-08-30 17:30:56 UTC
please note that with the recently increased row limit the bitmaps involved also
increased drastically in size, usually running into an allocation error.
Comment 9 miximka 2013-08-05 10:11:22 UTC

the same issue still reproducible on the latest OS X - 10.8.4 with the latest OO release: AOO400m3(Build:9702) - Rev. 1503704

The issue is easy to reproduce:
1. Open OO, create new spreadsheet
2. Copy column
3. Open Clipboard in Finder ("Edit" menu -> "Show Clipboard")
4. OO hangs & Finder hangs as well

The issue seems to be caused by the huge amount of data copied to clipboard when some other application (i.e. Finder or any 3rd party clipboard manager) tries to read the content of the clipboard. This seems to cause OO to generate a lot of data and copy it to the system clipboard.

From my analysis, it seems to be a RTF data type flavor being copied on clipboard, that causes the problem (more than 1 Mio. of lines get converted to RTF format and copied on the clipboard, but why? they were never been edited...)

During data generation, both OO and Finder eat a lot of physical memory (up to 1.2 GB for each of them) so that explains why crashes are not confidently reproducible - the apps would only crash if there are not enough memory.

The issue will always occur if user has some 3rd-party clipboard manager installed on his system (that is the case on my system) because these apps always try to catch entire clipboard content when it changes for the history purpose but this event always ends with an unresponsive OO and the 3rd party app...

Best regards,
Comment 10 sycer 2013-08-05 10:35:00 UTC
I just took sometime and found, that this issue is already posted under:

Bug 99371
Bug 54064
Bug 109365
Bug 53526
Bug 99371

Someone please put this alle together into one big bug - so that please someone code it the way, that my Finder don't crashes (Mac OSX 10.6.8) => means: not copying empty cells. Thx.
Comment 11 Marcus 2017-05-20 11:11:51 UTC
Reset assigne to the default "".