Re: [lmi] Fwd: Remarkable performance problem

[Vadim Zeitlin]

On Fri, 2 Mar 2018 17:42:58 +0000 Greg Chicares <address@hidden> wrote:

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

[Oops, sorry, I probably forgot to cc my previous reply to you: I had
stopped doing it manually after having changed my MUA to do this by
default, but then I changed that option back after you wrote that things
seemed to get back to normal and forgot that I had to do it manually again
when you wrote that they finally didn't. Anyhow, long story short, this is
entirely my fault.]

GC> On 2018-03-02 17:15, Greg Chicares wrote:
GC> > ---------- Forwarded message ----------
GC> > From: Vadim Zeitlin <address@hidden>
GC> > Date: Fri, Mar 2, 2018 at 3:18 PM
GC> [...]
GC> > On Fri, 2 Mar 2018 01:28:19 +0000 Greg Chicares <address@hidden>
GC> > wrote:
GC> [...]
GC> > GC> In light of new evidence, I wonder whether the cause is a combination
GC> > GC> of wine and applying 'sort_cell_subelements.xsl', because the patch
GC> > GC> below prevents the worst of the reported symptoms:
GC> 
GC> [...snip patch--it was mangled by webmail anyway...]
GC> 
GC> >  So how long does the call to cell_sorter().apply() take?
GC> 
GC> It takes much less time than reading the file. The statusbar says
GC> (I'm typing this in from the screen, so I'll reformat and abbreviate):
GC>   Read 1693 cells;
GC>    1969 ms validation
GC>    5987 ms reading
GC>   12207 ms reconciliation
GC>    7422 ms repeat
GC> The cell-sorter and XSD validation are combined in the "validation"
GC> line.

 Yes, this doesn't seem to take very long at all, compared to the rest. I'd
even say that it looks suspiciously fast, but maybe I'm just being
paranoid.

GC> > I.e. is there any real need for them to be
GC> > sorted and, if so, what is it?
GC> 
GC> Sorting is necessary only if XSD validation requires it.

 I think it does, but this would be easy to fix if it's not desired: we
need to use "interleave", which is represented by "&" in Relax NG compact
syntax that we use. I.e. instead of

    ,element case_default     {cell_element  }
    ,element class_defaults   {cell_element +}
    ,element particular_cells {cell_element +}

we should use

    element case_default     {cell_element  } &
    element class_defaults   {cell_element +} &
    element particular_cells {cell_element +}

I don't include the patch for this change because I didn't have the time to
test it yet, but I'm relatively sure it ought to work.

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

 I still have no explanation for this, the only possible reason I see would
be some horrible memory fragmentation, but this is more like magic
mumbo-jumbo than any real explanation because I can neither say why exactly
would this happen, nor even how to prevent it from happening. But I still
think that it would be better to avoid sorting unnecessarily in any case,
even if it's completely unrelated to the problem at hand.

 Regards,
VZ