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

List:       koffice-devel
Subject:    Re: KSpread - algorithm for fast and memory-saving storage of
From:       Norbert Andres <nandres () web ! de>
Date:       2003-04-25 19:04:58
[Download RAW message or body]

> >About memory: the style work is not completely finished if you compare
> > with OpenCalc. I plan to do that sometime.
> >
> >The memory consumption of the style solution and the area solution is
> > similar. If it were fully implemented the style solution would even use
> > less memory if every second cell has the same layout:
> >A B A B A B
> >This is hard to do with areas, you will end up with 6 different one, while
> >there were 2 with the OpenCalc style solution.
>
> Maybe I didn't get your point properly, but if you have 1 pointer per cell,
>
> 65'000 x 65'000 cells x 32bits/pointer = 16 Gigabytes just for the
> pointers !!!
I know of this problem - this is our main problem. But the pointer is just the 
smallest part because for the 65000*65000 cells KSpread 1.3 would need at 
least 950 GB (if all cells are empty) and about 1400 GB in KSpread 1.2.
I still want to encourage you to use the KSpreadStyle class, no matter how you 
organize the data, because this class implements most of the hierachical 
stuff and you just need to care about organizing it in the way you suggested.

The KSpreadCell class will nearly disappear in the future (the cell shouldn't 
contain any data - all the values/layouts should be shared) and maybe also 
the KSpreadLayout class.

> Re "Select All": The obvious solution would be to select only a
> rectangular area as large as the part that really contains data... and
> as long as you don't put a single number in the bottom right corner... ;-)
Okay, do that, change the cell height and scroll just one more cell and all 
cells below have the old height - this is not a really good way to do that 
and it's more cheating and not really what the users expects. This was one of 
my first patches for KSpread but it got rejected for that reason.

> Again, you guys that are familiar with KSpread's internas are in the
> position to decide... I just posted this idea because I read this
> comment in the source code and thought this idea may be useful.
I already said the idea is useful and also said I would like you to implement 
it.
The current classes KSpreadLayout and KSpreadCell are a mess. They are huge 
and removing the style pointer is a lot of work.
If you want to implement it for 1.3 hurry up. And even if you don't like it:
using the pointers (and just setting them correctly before using them) is a 
lot less work and maybe more stable because it doesn't change too much of the 
behavior in this classes.

For 1.4. we will rewrite the whole stuff anyway and hopefully do it right. 
Right now it is up to you. For 1.3 you have a bit more than a month. For 1.4 
til September/October depending on my/our progress with the rest of the code.
Again: I would like to have your solution and we will have to do something 
similar for the rest of the cell attributes (like merged cells,...)

It seems like you don't see any problems when loading or saving but I do. You 
will have to totally rewrite the way cells are 
saved/loaded/copied/pasted/drag'n'dropped. Right now these are a few hundred 
lines. I doubt that this is possible for 1.3 unless you have a lot of time.

But since we both agree on the direction I would suggest start implementing 
your solution for 1.4 and get this to work. We can merge it in directly after 
the release of 1.3 and then start to optimize the rest and think about 
switching to the OpenCalc file format.
Another reason for this suggestion is that I won't be able to help much for 
the next 1 or 2 maybe 3 months - answering the mails is already at the limit 
right now.

Would this be okay to you? 

Regards
Norbert

(Sorry if my mails are kind of confusing/unorganized)
_______________________________________________
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]