On Sun, 2011-06-05 at 02:04 +0200, Markus Mohrhard wrote:
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)
;-) FWIW - document -load- used to cause way more progress-bar updating
CPU cycles than it took to load the spreadsheet (the once-per-cell
notification did that).
I -believe- that I had a patch that used gettimeofday in the case that
a visibly different value would be shown in the progress bar - so just
one syscall per cell that sped that up a lot ;-)
Then I think (for import), someone introduced a thread - that sat in
'usleep' so we could throttle any updates to one every half-second or so
- which AFAIR was rather more efficient, and avoids a load of syscall
related slowness.
I -though- / hoped / etc. that that could be made more generic, so we
could have a progress-bar class that is ~impossible to use badly; of
course it mostly sucks to have a 'sleep' thread ;-) but ... it is only
one at a time.
So, I wonder if the UX guys don't mind us never updating a progress bar
more than twice per second (say) [1] we could do this for all progress
bars in one place. Clearly calling a
FooProgres->update(percent) method a bazillion times is not slow, if we
never re-draw anyway.
Thoughts ?
Michael.
[1] - and I don't expect it to be configurable ;+)
--
michael.meeks@novell.com <><, Pseudo Engineer, itinerant idiot
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.