Date: prev next · Thread: first prev next last
October 2011 Archives by date, by thread · List index


Hi Kohei, hi all!

Am Dienstag, den 25.10.2011, 20:40 -0400 schrieb Kohei Yoshida:
Hi Christoph,

Just one thing to consider regarding the performance impact of the
proposed change...

Of course ...

On Tue, 2011-10-25 at 23:26 +0200, Christoph Noack wrote:

Yep, would be one solution ... maybe we do some nasty tricks to make the
user believe it is a character-by-character update?
      * When changing a name / expression (e.g. entering a character),
        the system might check for the name / expression validity, and
        (if valid) update the table. The model stays unchanged. If the
        name / expression is invalid, further changes in the model
        mustn't be done anyway.
      * If the user exits the input field, then the model is updated and
        a undo item is created.

But still, I don't know whether its doable or solves the performance
issue. But I really think its very elegant ;-)

I agree that it would be an elegant solution.  However...

One issue we need to consider is that, once the name is updated in the
model, and assuming that the auto recalculation is turned on (it's on by
default and most users leave this on), all affected formula cells will
need to be re-calculated.  And this needs to happens every time a name
is updated.  Depending on how large the document is, and how complex its
formula network is, this can be very expensive.

Right now, all modified names are committed to the model once when you
click OK, so at most we have to re-calculate once.  But if the current
proposal becomes implemented, then we would need to do re-calc on every
name definition change.  That would potentially make the whole name
updating experience unpleasant.

If the dialog was modal, we could temporarily turn off auto-recalc and
turn it back on once the dialog is dismissed, but we can't do that with
modeless dialog.

Sorry to give you guys another obstacle.  But I felt I needed to mention
this to make sure this issue is taken into consideration in the design.

Of course, thank you ... you also pointed towards another issue I wasn't
aware about - but that's another story.

Coming back towards the issue of "performance", what's the impact we
talk about? Markus once mentioned that you have a file with approx. 600
range names ... maybe you have some files that already cover even more
range names incl. complex calculations.

In such a case, what's the impact we talk about? I simply don't have a
clue ... it could be 100 ms ... 10 seconds per update on an average PC
(whatever average means). Would it be possible to get such a file?

Cheers,
Christoph


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.