[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice
Subject:    Re: kspread slowness with a lot of data
From:       Philipp =?iso-8859-1?q?M=FCller?= <philipp.mueller () gmx ! de>
Date:       2003-02-22 20:45:17
[Download RAW message or body]

On Saturday 22 February 2003 18:28, Vladimir Dergachev wrote:
> Also I have tried your Ctrl-Shift-Arrow operations. With down arrow it
> works great ! (fast and easy) Thanks !

I learned this feature because there was a bugreport about this not working 
;-)
Now I'm impressing my colleagues in my company with these shortcuts.

> But with up arrow I see the exact same delay. (I am putting the cursor in
> cell G12645 and pressing Ctrl-Shift-Up Arrow).
>
> The delay is very long, way longer than even pressing Ctrl-Shift-Down arrow
> in an empty column (which highlights all 32000 cells).

Yepp. I've seen that before but forgot to investigate more.

Just do following key steps: 
- Select A1 
- CTRL-SHIFT-DOWN (everthing is still fine)
- SHIFT-UP (now it's slow, even the only difference is that we select the 
whole column minus one row).
- Now do some SHIFT-RIGHT (it gets slower and slower)
- Now do one SHIFT-DOWN (everything is fast again).

I asume this has to do with the autocalculation of the values (the auto sum in 
the status bar), as this should be the only place where we do something with 
the cells in between.
Maybe we generate here nonDefaultCells for the cells in between for the case 
we don't have full columns/rows selected?
I didn't investigate here. If you wanna help, here is a good start ;-)

Thinking of where to search:
kspread_canvas contains the ctrl-key reaction, kspread_selection all the 
selection code and kspread_sheet the basic functions for calculation.

> As for memory this is not a big problem. With 7 columns filled with 12645
> cells kspread SIZE (as reported with top) is 427Megs. This system has 1G
> of RAM so no swap issues. Also 300 bytes * 12000 = 36megs - quite
> acceptable.

427Megs is not acceptable. This would mean our cell has 3000 bytes. Okay top 
is not very accurate, but a factore of ten makes me wonder. My guess of 300 
bytes was the result of size(KSpreadCell). KSpreadCell itself contains 
objects, so the size may be much higher.

> One more thing - I just tried saving the file and I saw the memory usage
> jump up and then down (but above what it was before).

This looks okay. I think here top is simply not accurate enough.

> Could it be that the delay is caused by kspread saving all data for Undo,
> even though I am only inserting a chart in a different sheet ?

No, I can only assume that when you insert a chart, you change a value and 
then the autosave starts saving your changes...

> (No, I don't think it would be a good idea for me to take over a part..
> but I would really like to trace down this slowness.

Hopefully my hints above helps already.

> Also I'll take a
> look at the cell size issue, perhaps there is an easy way to fix this).

Sadly to say, I doubt there is an easy fix possible. This is about changing a 
fundamental part of KSpread. Or in other words, this is about a basic design 
failure.

Philipp
____________________________________
koffice mailing list
koffice@mail.kde.org
To unsubscribe please visit:
http://mail.kde.org/mailman/listinfo/koffice
[prev in list] [next in list] [prev in thread] [next in thread]