Difference between revisions of "Calc/Performance/misc"

Revision as of 21:07, 17 March 2006

Calc Optimisation Opportunities

There are a lot of opportunities in calc for various reasons. This list needs extending:

Cell size

Basic problem: the most basic cell consumes about 50bytes all told, more complex cells consume far more memory, there are a number of simple & obvious things to re-factor here.

ScBaseCell

sc/inc/cell.hxx:

class ScBaseCell
{
protected:
	ScPostIt*		pNote;
	SvtBroadcaster*	pBroadcaster;
	USHORT			nTextWidth;
	BYTE			eCellType;		// enum CellType - BYTE spart Speicher
	BYTE			nScriptType;

Every cell carries this overhead; note that a chunk of it is not necessary for many cells:

• ScPostIt pointer - very, very infrequently used - we have almost no post-it note per cell.
• SvtBroadcaster - used by cells that are referenced (by a single cell (ie. non-range) reference) from another cell - again, a sub-set of all cells.

Solutions: a little re-factoring required, but stealing a bit-field from eCellType to denote a 'special' cell:

class ScBaseCell
{
protected:
	USHORT			nTextWidth;
	BYTE			eCellType : 7;  // enum CellType - BYTE spart Speicher
        bool                    bSpecial : 1;   // other information to be looked up elsewhere
	BYTE			nScriptType;

The 'bSpecial' flag could be used to denote that there is a 'note' for this cell (in a separate hash), or that this cell has a single-cell dependant. So - we can save 2/3rds of the base size with fairly little effort.

ScFormulaCell

Problems here.

In-sheet objects

Horribly slow - some VCL & svx issues here.

Large / complex pivot sheets

Jody has some sample data here - links ? - internal Novell sheet (commonly used) taking ~3 hours to re-compute.

threaded calculation

Ideally to scale to hyper-threaded machines we need to crunch a workbook's dependency graph & then thread the calcuation.