Re: [lmi] Remarkable performance problem

[Greg Chicares]

On 2018-02-28 13:15, Vadim Zeitlin wrote:
> On Wed, 28 Feb 2018 01:54:15 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> Vadim--Do you have any idea what I might try next?
> 
>  Assuming that the problem is Wine-specific, which seems reasonable
In light of new evidence, I wonder whether the cause is a combination
of wine and applying 'sort_cell_subelements.xsl', because the patch
below prevents the worst of the reported symptoms:

---------8<--------8<--------8<--------8<--------8<--------8<--------8<-------
diff --git a/multiple_cell_document.cpp b/multiple_cell_document.cpp
index a15421470..b543ae7fd 100644
--- a/multiple_cell_document.cpp
+++ b/multiple_cell_document.cpp
@@ -427,7 +427,7 @@ void multiple_cell_document::validate_with_xsd_schema
 {
     xml::schema const schema(xml_lmi::dom_parser(AddDataDir(xsd)).document());
     xml::error_messages errors;
-    if(!schema.validate(cell_sorter().apply(xml), errors))
+    if(!schema.validate(xml, errors))
         {
         warning()
             << "Validation with schema '"
--------->8-------->8-------->8-------->8-------->8-------->8-------->8-------

[Suspecting that I might be using xsltwrapp incorrectly, I also tried:
-    if(!schema.validate(cell_sorter().apply(xml), errors))
+    xml::document const sorted_doc = cell_sorter().apply(xml);
+    if(!schema.validate(sorted_doc, errors))
which did not help. And this alternative:
+    static std::string const f("sort_cell_subelements.xsl");
+    xslt::stylesheet z(xml_lmi::dom_parser(AddDataDir(f)).document());
+
     xml::schema const schema(xml_lmi::dom_parser(AddDataDir(xsd)).document());
     xml::error_messages errors;
-    if(!schema.validate(cell_sorter().apply(xml), errors))
+    if(!schema.validate(z.apply(xml), errors))
actually made the problem worse.]

But this workaround is no solution. The XSD schema, IIRC, requires that
<cell> subelements be sorted, and fails if they are not. The particular
test case we're working with appears to have its elements already sorted,
but that won't be true for other cases (different vendors supply various
versions of lmi input files, each with its own anomalies). We need to
sort the subelements in files from external vendors.

Anyway, the experimental patch above narrows our search for the ultimate
cause of the gravest problem, namely, gross GUI unresponsiveness. It does
not affect the less grave secondary problem, namely, that running a case
becomes prog res siv el y  s  l  o   w   e      r, but that's certainly
an entirely different issue.