[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:       John Dailey <dailey () vt ! edu>
Date:       2002-03-25 14:33:15
[Download RAW message or body]


> 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.
Isn't that exactly what we need?  It's a reference to any cell stored in 
arrays for fast, efficient access -- grouped in blocks so that we can skip 
past large areas of unused cells.  

Absolute worst case scenario is if the first and last cell in a column are 
used.  There's 127 cells left in the level2 cluster, 254 unused level1 
clusters, and then 127 empty level2 cluster cells before the last cell.  So 
we basically loop 508 times testing if cluster[blah][blah] == NULL.  Fast!  
How much more efficiency would we need?  I don't think it's worth it to put 
in up/down/left/right pointers and then maintain them.

I'll go ahead and implement this -- there's lots of places where it would be 
useful.  Right now, there are lots of places in the cell layout code that 
loop through every cell in the spreadsheet and then test if it's in a 
particular column.

-John


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

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