From koffice Sat Feb 22 21:55:59 2003 From: Vladimir Dergachev Date: Sat, 22 Feb 2003 21:55:59 +0000 To: koffice Subject: Re: kspread slowness with a lot of data X-MARC-Message: https://marc.info/?l=koffice&m=104595108530504 > > 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. But before this I have to check out the CVS.. ... time passed ... 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. 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) 3) What does "const;" in the end of method declaration mean ? 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). thank you Vladimir Dergachev > Philipp > ____________________________________ > koffice mailing list > koffice@mail.kde.org > To unsubscribe please visit: > http://mail.kde.org/mailman/listinfo/koffice > ____________________________________ koffice mailing list koffice@mail.kde.org To unsubscribe please visit: http://mail.kde.org/mailman/listinfo/koffice