Re: [lmi] Fwd: Remarkable performance problem

[Greg Chicares]

On 2018-03-04 00:38, Vadim Zeitlin wrote:
> On Fri, 2 Mar 2018 17:42:58 +0000 Greg Chicares <address@hidden> wrote:
[...]
> 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> 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.

This file happens already to be sorted. Of course, not all sort algorithms
perform well on already-sorted data.

> 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 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.

I don't think that change will be wanted:

- IIRC, "interleave" doesn't let us diagnose missing elements well.

- See the "Primary...Secondary...Tertiary" comments in 'test_schemata.sh'.

- Validation has to be built into lmi. I'm not willing to have it
  depend on "java". In light of the commentary referenced in the
  preceding point, that means we have to use XSD, not RNC or RNG.

> GC> The problem is not that invoking the cell sorter takes long.
> GC> The problem is that invoking it makes the GUI so unresponsive

[...snip how awful it is...]

>  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.

I've been so busy migrating to debian "buster" and MinGW-w64 gcc-7.2
that I don't think I've mentioned that this awful thing doesn't happen
in that happy new world. I imagine this was just some horrible problem
that is no longer present in 'wine'. Maybe libxslt wrote some part of
memory where 'wine' stored a usable video driver, so it fell back on
a practically unusable one. Or something like that.

> 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.
Can't--see above.