[Libreoffice-ux-advise] [Libreoffice] Performance improvements for calcs' sheet actions

Cor Nouws oolst at nouenoff.nl
Sun Jun 5 02:24:25 PDT 2011


Hi Markus, *,

Markus Mohrhard wrote (05-06-11 02:04)

> I've been looking a bit further into the performance problem when
> dealing with several sheets and am now at the move
> method.(ScDocument::MoveTab)

With the few sheets that I tend to work with, never even noticed a 
progress bar ;-)
But that does not mean there is no (possible) problem of course.

> We have there an ScProgress(for all: it's the calc version of a progress
> bar) which is called quite too often. We call for every column at every
> sheet ScProgress::SetState. So in the end we are there with number of
> tables * MAXCOL (which is 1024 at the moment) calls to SetState. (It
> gets even worse when we move several sheets at once: number of moved
> tables*number of tables*MAXCOL)
>
> I tried with 5000 empty tables and moving a sheet from the first
> position to the last(most work for the algorithm) and it turns out that
> we need much more time updating the progress bar than we need to move
> the sheet. So in my opinion there is no need for the progress bar but I
> like to hear your opinion on that too. I don't know if you remember that
> we have problems with the same progress bar in the unit test, so it
> would solve two problems at once.
> The other solution would be to update the progress bar only once per
> sheet and not once per column.

Looks logic to me.

> I would like to here any suggestions before I change anything UI related.

There is a list for it recently -added as CC. (See
http://lists.freedesktop.org/archives/libreoffice/2011-June/013109.html )


> P.S. We don't even use a ScProgress in ScDocument::CopyTab which should
> normally need much more time

Regards,

-- 
  - Cor Nouws
  - http://nl.libreoffice.org



More information about the Libreoffice-ux-advise mailing list