In some cases, at least with complex-enough views, inserting many
options in a document in a row will get progressively slower.
In import, this issue is hit on trying to import partners: partners
have a humongous number of fields (direct and on their o2m), ~940,
which yields a correspondingly huge number of options in the
selection.
A basic partner export also has quite high a number of columns (~50
without exporting o2m fields), so this list of 940 options is inserted
50 times in a row (literally too, they're all in the same table row)..
While not all that fast, Firefox 5/6 has no significant issue with
this (~18ms/insertion, where an insertion is a full select with all
its options). Webkit browsers (Chrome and Safari) on the other hand
start out fair (~10ms/insertion), but get slower and slower until they
end up at 3~5 *seconds* for each insertion (3s if inserting a
DocumentFragment, 5s if inserting text via innerHTML). This means the
preview table takes up to *two minutes* to display, even the best
cases (pre-generating everything that can be and optimizing everything
I could think of) take 75 *seconds* for the insertions (the
pregeneration of a given select and its options is ~100ms, the base
template rendering is ~20ms).
rendering divs or inputs does not have this issue, I did not manage to
reduce or fix the issue directly so I replaced the options by
jQuery-ui's autocomplete widget. This is not issues-free: when tabbing
through the fields lists, when reaching the edge of the popup the
browser will automatically scroll the field back into view. However,
this is done *after* autocomplete's popup has opened, and as a result
the popup opens in the wrong place (at the popup's edge, instead of
under the now-moved field).
bzr revid: xmo@openerp.com-20110922085812-3u1esk6czraskm01
Antoine Huvelle