[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]