[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-15?q?M=FCller?= <philipp.mueller () gmx ! de>
Date:       2003-02-23 8:32:46
[Download RAW message or body]

Hello Vladimir,

we should move this thread to koffice-devel.

On Saturday 22 February 2003 22:55, Vladimir Dergachev wrote:
> > > 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.
> 
> Well, I really have to look at the code for this, but my preliminary plan
> was to separate some of the fields into an attribute struct and let the
> cells only keep a pointer to it.
> 
> The attribute structs would have a use count and when use is greater than
> one there would be a copy-on-write policy.
> 
> Lastly the attributes structs could be hashed for easy merging so that
> group operations (change color of 1000 cells to red) do not require extra
> work in the code.

Yes, this is one of the 3 concepts, we intend to do for the layout stuff.
We call it 'flyweight' system. See the description of John: 
http://webcvs.kde.org/cgi-bin/cvsweb.cgi/koffice/kspread/FORMATTING_DESIGN?rev=1.1&content-type=text/x-cvsweb-markup


The other 2 concepts are about a style manager and ranges.
All 3 together will make KSpread perfect, it's not either / or.

Additional you should have a look into the mails we had in December on the 
koffice-devel ML:
http://lists.kde.org/?l=koffice-devel&m=103956168404091&w=2
http://lists.kde.org/?l=koffice-devel&m=103979269812417&w=2
http://lists.kde.org/?l=koffice-devel&m=103981153401737&w=2
http://lists.kde.org/?l=koffice-devel&m=103988640810489&w=2
http://lists.kde.org/?l=koffice-devel&m=104014455230215&w=2

> I have taken a look at the code (Gahh ! This seems to be the heaviest
> use of C++ that I saw since mozilla) and I have lots of questions.

Hehe, of course this is C++. Some questions others should answer, as I'm not a 
C++ guru. Maybe Ariya or David?

> 1) How can I tell whether a given method in a class (specifically
> KSpreadCell) is assigned an entry in a virtual table or not ?
> 
> 2) Am I correct in noting that KSpreadCells are not being aggregated
> anywhere in kspread ? (I looked at KSpreadSheet and KSpreadCluster
> objects)

With aggregation you mean "shared" somehow? The value itself is shared (see 
below). But we should focus on the layout stuff, don't bother at the moment 
about stuff like nextCell, dependOn, etc.
Layout information is currently not shared. But we have them stored redundant 
at 3 places: default Cell, Rows/Columns and the Cell itself. 

> 3) What does "const;" in the end of method declaration mean ?

That the method doesn't change any value.

> 4) I am correct in thinking that all cells elements are stored
> as strings. (I.e. m_strText and m_strOutText are the only
> places which store cell value).

Not really. The elements are stored in KSpreadValue. This is a shared object 
with copy on change.
m_strText and m_strOutText are there only for performance issues (which is 
IMHO not necessary). KSpreadValue stores e.g. 1034.5623, then m_strText 
contains the formated string e.g. 1035.6 ¤ and m_strOutText contains the real 
output e.g. limited width of a cell 1035.
The recalculation of m_strText and m_strOutText is done via makeLayout. I see 
no real point in storing them in each cell, when we can recalculate them on 
paint.

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]