Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of gcaiod-ooo-dev@m.gmane.org
 designates 80.91.229.12 as permitted sender)
To: ooo-dev@incubator.apache.org
From: Joost Andrae <Joost.Andrae@gmx.de>
Subject: Re: Slooooow spreadsheet documents
Date: Mon, 10 Oct 2011 23:35:05 +0200
Lines: 27
Message-ID: <j6voab$jbe$1@dough.gmane.org>
References: 
 <CAP-ksoiUF+oS39tU14rPWfGzwATuE_02AGqW2ZfRfdr6uBQU_g@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
In-Reply-To: 
 <CAP-ksoiUF+oS39tU14rPWfGzwATuE_02AGqW2ZfRfdr6uBQU_g@mail.gmail.com>

Hi Rob,

just a remark:

In my private opinion it would make more sense to invest resources into 
impementing a formula reference which points to expanded formula cells 
(/edit/fill) like it is already done for formatting templates within the 
sheet.
A slow sheet doesn't necessarily mean that calculation is slow. Better 
resolving references within the sheet (in my opinion) has more potential 
to make such documents faster. I believe by using formula references the 
documents' memory footprint could be lowered as well because a formula 
reference doesn't cost as much as a cell content containing a formula 
and containing edit engine data.

At one of the OOo conferences I vaguely remember there was a university 
project that already parallelized computation of Calc sheets. 
Unfortunately I cannot remember the project/university name anymore. 
Probably having a look at the conference session drafts might give us 
some more insight.

>
> I was talking to someone earlier who had ideas for speeding up
> spreadsheet computation through parallelization, and was looking for
> some notoriously slow test documents.

Kind regards, Joost