Re: [lmi] Fwd: Remarkable performance problem

[Greg Chicares]

[...I received this from the mailing list through a web-mail service,
but not through my ISP; I was able to forward it from there to my ISP,
and am replying to the forwarded message, so threading is probably
borked...]

On 2018-03-02 17:15, Greg Chicares wrote:
> ---------- Forwarded message ----------
> From: Vadim Zeitlin <address@hidden>
> Date: Fri, Mar 2, 2018 at 3:18 PM
[...]
> On Fri, 2 Mar 2018 01:28:19 +0000 Greg Chicares <address@hidden>
> wrote:
[...]
> GC> In light of new evidence, I wonder whether the cause is a combination
> GC> of wine and applying 'sort_cell_subelements.xsl', because the patch
> GC> below prevents the worst of the reported symptoms:

[...snip patch--it was mangled by webmail anyway...]

>  So how long does the call to cell_sorter().apply() take?

It takes much less time than reading the file. The statusbar says
(I'm typing this in from the screen, so I'll reformat and abbreviate):
  Read 1693 cells;
   1969 ms validation
   5987 ms reading
  12207 ms reconciliation
   7422 ms repeat
The cell-sorter and XSD validation are combined in the "validation"
line.

> GC> But this workaround is no solution. The XSD schema, IIRC, requires that
> GC> <cell> subelements be sorted, and fails if they are not.
> 
>  We shouldn't be sorting cells if it needs to be done just for the
> validation to pass, should we?

XSD validation is a requirement, because the source is not reliable.

I believe the XSD schema fails if <cell> subelements are not sorted.

> I.e. is there any real need for them to be
> sorted and, if so, what is it?

Sorting is necessary only if XSD validation requires it.

> I guess that sorting relatively big files is
> not going to be very fast in any case, so if we could avoid it, it would
> seem to be much better to do it.

It seems to be fast enough: it's just a minor proportion of the
total load time reported on the statusbar above.

The problem is not that invoking the cell sorter takes long.
The problem is that invoking it makes the GUI so unresponsive
that if I switch to another application and back by pressing
alt-tab twice, the switch away is immediate, but the switch
back can take more than five seconds. To be really clear,
I'm not switching *during* the cell sort: I'm saying that the
mere fact that the cell sorter was invoked makes the GUI
disastrously slow, after the cell sorter has finished running,
and continuing until I close lmi.