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

List:       koffice-devel
Subject:    Re: KSpread bug (was Re: KOffice-1.2 release schedule)
From:       Philipp =?iso-8859-1?q?M=FCller?= <philipp.mueller () gmx ! de>
Date:       2002-03-25 7:58:42
[Download RAW message or body]

Am Sonntag, 24. März 2002 23:00 schrieb John Dailey:
> > I will implement this during my vacation.
>
> Just one small thing to throw in -- whatever you end up doing, try not to
> add any more data to KSpreadCell if at all possible.  
> Try to implement this in the cluster.

No, not the perfect place. The cluster is some kind of a fixed map of pointers 
(always x times y), regardless if filled or not. It doesn't help you cycling 
through _filled_ cells. In comparison to KSpreadCell we would even loose more 
memory, if we optimize for performance at this place.

But maybe for an easier implementation this can help for cycling through 
_existing_ cells in a direction (but keep in mind, that a cluster doesn't 
know if the cell is filled or not (it knows about the existence) and a 
cluster builds up always clusters of 128x128 columns/rows regardless filled/ 
not filled-you end up with 8 filled columns having 120 not filled).

>  KSpreadCell is fairly large as it is, and it's one class
> that you might conceivable have thousands or hundreds of thousands of
> copies of in a spreadsheet.

Yes, but the idea is to use a similar approach like nextCell/previousCell in 
KSpreadCell.

Maybe for the cycling through rows, we can use the existing 
nextCell/previousCell and in horizontal direction we don't need the same 
speed as in vertical.
But for the vertical approach I really favorize a top/bottomCell information 
(16 bytes per _used_ cell against the performance).

Philipp
_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]