tdf#50916 : Calc : Dynamic column container

[Kohei Yoshida]

So, I'm gonna reply to Eike's post, but my reply is not in response to
Eike's, but just a general idea I have on this subject.

I had already discussed this with Markus before he posted his, and his
post also reflects my view on this in general.

First off, allowing dynamic growth of column container is purely an
implementation detail i.e. at the UI level the column size should be
fixed.  What we aim to achieve is to not statically allocate column
instances for the max number of columns on launch.  Instead, grow the
allocated space based on how many columns store data.  On that front,
Markus already provided what needs to be done, and I believe Dennis
already gets it.

At higher level, there are two aspects to this.  One is improving the
storage efficiency of ScColumn, which I believe we already know what
needs to be done.

The other one is about improving algorithm used to access data stored in
ScColumn currently.  When you read through Calc's currently code, you'll
see a lot of code that looks like this:

        for (nCol=0; nCol<=MAXCOL; nCol++)
        {
            // do something here...
        }

In a lot of places we do go through the whole column array to get
something done.  That may be ok when the maximum column size is 1024,
but if we were to increase the max column size, we do need to do better
than this.

The idea about reworking the attribute storage by storing some of that
as row attributes or document attribute was about solving this with
regard to drawing cell attributes, by improving storage and algorithmic
efficiency of what is currently stored in ScAttrArray.

Aside from that, there are many other places where we could use
improvement.  Just grep through Calc's code for MAXCOL and find all
instances of for loops where we currently iterate from column 0 to
column MAXCOL, and try to remove that inefficiency, by perhaps moving
the data from ScColumn to somewhere else, or ....

That's the very high level overview of what needs to be done.  I guess
what I need to emphasize is that switching the storage for ScColumn is
just one piece of the puzzle; there are lots of other problems that need
to be resolved in order to make this all work.

The good news is that, this can (and perhaps should) be done
incrementally.  Going through each of the 0-to-MAXCOL-iterated for loops
and eliminating that one by one can be done one at a time.

That's all I have to say at the moment.  I admit this is a bit of an
abstract thinking, but I think what Markus and Eike already said should
provide enough specificity about this, so I'm just trying to add a bit
of a high level view.

Also, this will be an on-going process.  This is not going to be like
"if you do A, B and C it's okay to increase the column size and no
problems will occur".  Rather, we'll probably encounter lots of
performance issues that we'll have to spend some time fixing after the
column size is increased.

Kohei