You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
98 lines
4.1 KiB
98 lines
4.1 KiB
I just want to store some notes here in CVS as a compilation of
|
|
what I understood from some previous discussion on redesigning -- wanted
|
|
to do this before it is forgotten. It is very unlikely that I am
|
|
going to have the time/motivation to do this myself but hopefully
|
|
this can help give a start to whomever does the work. I don't think
|
|
anything here is definitive, and certainly if there are better ideas
|
|
than we should scrap these. For Norbert/Phillip/Ariya this is just
|
|
to help keep track of our ideas, and hopefully the future will see
|
|
many more KSpread hackers who can use this as a head-start in thinking
|
|
about KSpread design.
|
|
|
|
|
|
NOTE: when I say 'pointer' in this description, I'm thinking of some shared
|
|
object kind of class with a reference count -- not a literal pointer
|
|
that we would have to remeber to delete...
|
|
|
|
|
|
|
|
The problem needing solved is that the class KSpreadCell (which has
|
|
about a billion instantiations during a run of the program) is several
|
|
hundred bytes. This is a tremendous waste of space, and most of it
|
|
is spent holding information such as font type/size/color, which borders
|
|
to draw and line thickness, background color, and so on. Since this
|
|
information is going to be identical for a vast majority of cells, we
|
|
should find an efficient way to share data among cells.
|
|
|
|
The first idea is to break the format information into small classes,
|
|
such as one for font size/type, one for border information and so on.
|
|
The way to save memory is to use a 'flyweight' system in which cells
|
|
would have a pointer to the data, so cells with the same formatting have
|
|
the same pointer and the information itself has only a single instantiation.
|
|
|
|
At first, we can simply use the copy constructor of this class to implement
|
|
the sharing, and if it seems profitable in the long run these classes
|
|
can keep some kind of static mapping so that in the constructor a check
|
|
can be done to see if, for instance, helvetica font size 12 has already
|
|
been allocated in the past and use that pointer rather than allocating
|
|
a 2nd instance.
|
|
|
|
|
|
|
|
|
|
Next, these format objects would be collected objects I was calling 'styles'
|
|
A style would basically be one of every type of Format object and thus
|
|
would completely define the format of the cell. A style can be shared the
|
|
same way as a format object -- if two cells have all identical format
|
|
objects than they can share the same style object.
|
|
|
|
|
|
|
|
We had discussed two different ways of actually mapping these formats
|
|
and styles to particular cells.
|
|
|
|
One way is to simply have
|
|
each cell contain a pointer to its style. Rather than each cell using
|
|
200ish bytes to store the formatting, it has the single 4 byte pointer,
|
|
and then the the 200ish bytes is shared among all cells with that same
|
|
formatting information.
|
|
|
|
The other possibility is to map it by region. This involves storing
|
|
a map of some sort in KSpreadSheet to say, cells A2:E30 have this style,
|
|
column H has this style, etc. Here, the cell itself would store no
|
|
formatting.
|
|
|
|
If I remember correctly, we were leaning towards the second
|
|
method because of both the memory consumption, and because it is a simpler
|
|
way of handling setting formatting on a full column or row. However
|
|
this method will be much more complex to implement in a way that there
|
|
can be efficient lookup to retrieve the current style for a particular cell.
|
|
|
|
|
|
|
|
Some things to decide:
|
|
|
|
How fine grained to make the format objects?
|
|
- How much information to store in each format object. If there are a few,
|
|
large format objects, than each Style is very small, requiring only a
|
|
single pointer for each of these few format objects. However the data
|
|
sharing is not very efficient if between 2 cells the font color changes, and
|
|
there are 10 other pieces of data that are exactly the same
|
|
|
|
If there is too little in each format object, than we don't gain any
|
|
savings in memory because each additional type of format object results
|
|
in an extra pointer in each style object
|
|
|
|
|
|
|
|
|
|
|
|
There's probably much more that can be put in here.
|
|
|
|
|
|
BTW, I hope to stay involved at least a little with KSpread. It is unlikely
|
|
however that I will try to take on any large chunks of code unless I just get
|
|
in a random programming fit on a weekend :-)
|
|
|
|
-John
|