Issue 42462 - extremely poor rendering performance for non-trivial numbers of form controls
Summary: extremely poor rendering performance for non-trivial numbers of form controls
Alias: None
Product: Calc
Classification: Application
Component: code (show other issues)
Version: 680m77
Hardware: Other Linux, all
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2005-02-10 20:37 UTC by mmeeks
Modified: 2017-05-20 11:13 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

a slow, slow file (19.16 KB, application/vnd.sun.xml.calc)
2005-02-10 20:37 UTC, mmeeks
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description mmeeks 2005-02-10 20:37:29 UTC
With the attached spreadsheet - which implements approximately 250 list-boxes in
a single sheet [ a cut-down version of a real-world use case ], we get
staggeringly bad performance.

* A big chunk of this seems to be the cost of instantiating the list-box - which
(it seems) involves lots of X-server traffic some of it of very dubious
usefulness [ setting window titles of unlikely-to-be-used floating windows etc. ]

* Another chunk I imagine is possibly vcl not scaling very nicely to having a
thousand-or-so peers of the one window; at destruction time we have a huge
slow-down but perhaps that's via call-backs or somesuch.

* scrolling is also really direly performing :-)

* The main cause of the evilness though I think is the SdrPageView - which
insists on instantiating (I assume 4 times over - due to the double sheet split
], hundreds of occluded controls.

My profiles show time being consumed down this sort of path:

SdrPageView ImpInsertControl() -> UnoControlContainer::addControl ->
UnoListBoxControl::createPeer -> ListBox::ListBox etc.

I'd be interested in an acceptable design to accelerate this; for example - it
seems to me rather futile doing all this work immediately, when we could perhaps
move the body of ImpInsertControl (wrt. control construction & placement) inside
the SdrUnoControlRec - and instantiate all of that weight, only when the
SdrUnoControlRec object becomes visible.

Unfortunately given my limited understanding how how any of it works - it's
rather difficult to work out what's going on; pwrt. the co-ordinate systems
involved. I infer from the 'view' in 'SdrPageView' that there must be a per-view 
translation applied to all controls - to allow views to have different origins,
but - that appears no-where to be the case.

Either way - I'm interested in tackling this issue, but - will need some advice
Comment 1 mmeeks 2005-02-10 20:37:56 UTC
Created attachment 22426 [details]
a slow, slow file
Comment 2 wolframgarten 2005-02-11 08:06:32 UTC
Changed component.
Comment 3 wolframgarten 2005-02-11 08:06:49 UTC
Comment 4 mmeeks 2005-02-11 08:38:25 UTC
wg: since the poor performance seems to be isolated primarily in algorithmic
badness in svx/ how then is this a spreadsheet bug ? Of course, I can spend some
time generating a draw document that exhibits the same behavior [ I imagine ] -
is that necessary ?
Comment 5 frank 2005-02-11 09:28:13 UTC
Hi Frank,

as controls are your construction site this may be yours.

Comment 6 Frank Schönheit 2005-02-11 11:05:20 UTC
Ah, form control performance ...

Things I know so far about this (I investigated a while ago in the course of
another issue):

- One problem is that the ListBox in VCL creates a floating window all the time,
  if not needed. Normally, we could argue that this window is only needed when the
  (drop down) list box is to really open its floater... Unfortunately, the whole
  architecture is based on the ImplWindow, whose parent is the floating window, even
  for (normally unrelated) operations.
- The code at the very end of UnoWrapper::WindowDestroyed in
  toolkit/source/helper contains a loop over all top level windows which currently
  exist. Due to some outdated architecture in VCL, this has a complexity of O(n^3)
  (not only O(n^2), as you would assume), with n being the number of system
  windows. Unfortunately, the above-mentioned floating windows *are* system
  windows, so this sums up pretty quickly (a document with 2000 list boxes can
  take *hours* to open or close).
  This explains at least the performance problem when closing such a document,
  and in parts also when *opening* (where also all controls are
  created/destroyed/created for some reason).
  I have a patch for this O(n^3) problem, but not checked in, and it's missing some
  polishing requested by SSA, which I did not yet find time for.

Immediate ideas:
- Make the listbox not creating a floating window, unless really necessary. The
  VCL people did not dare :) to do this in the 2.0 time frame, due to some
  risks associated with it.
- create peers only if necessary, as suggested by you. I don't have the
slightest idea
  whether and how this could work, since this touches areas of the drawing layer
  where our form controls are only "guests", and which I rarely needed to look at
  (it was there long before I inherited the code :).
  I cc Armin Le Grand here, who's our drawing layer expert.
  Nevertheless, I'm willing to help to work on this, not only 'cause I am pretty
  I can learn a lot 'bout the drawng layer here :)
Comment 7 Frank Schönheit 2005-02-11 11:07:04 UTC
And no, this is not really a spreadsheet issue, but spreadsheets seem to stretch
this problem to its worst, so I suggest keeping the spreadsheet document as a
working base.
Comment 8 Frank Schönheit 2005-05-10 13:39:40 UTC
targeting to "Later" to get rid of "no target" issues. Not really reasonable for
Comment 9 Marcus 2017-05-20 11:13:49 UTC
Reset assigne to the default "".