TimeTable models reported to fail in NF because of timeout

[Francesco Casella]

Please check the performance of the TimeTable_N_XXX models ​with the new FE.

The smaller one passess the FE in less than one second. The other ones fail after four minutes with error:

Timeout error for cmd: translateModel
CORBA.COMM_FAILURE(omniORB.COMM_FAILURE_WaitingForReply, CORBA.COMPLETED_MAYBE)

OMC output: Created server.
Dumped Corba IOR in file: /tmp/openmodelica.hudson.objid.b4e73b4151354beabc9d034ff413389d
Started the Corba ORB thread with id: 140613055231744
Terminated

Apparently some setup (hash table size, buffers, whatever) is not appropriate for models containing large parameter arrays?

[Per Östlund]

They do not fail in the NF, they fail in the backend. But the way they fail causes the test script to not know where it failed, so it just assumes it didn't pass the first phase.

The performance is actually perfectly fine in the NF, the largest model (TimeTable_N_16000) takes less than 0.8s to pass the NF for me (with an OMC compiled for debugging, i.e. -O0 -g). I don't know how long the old frontend takes, I got tired of waiting after ~8min.

The backend is fairly fast with the old frontend though, so obviously something is wrong in the model the NF produces. It looks like it might be the same issue as in #4884, but I haven't investigated the issue in detail.

[Francesco Casella]

OK. I understand #4884 has rather far-reaching consequences on performance in many cases, even though the backend can handle that somehow, so I'll wait until it's fixed.

[Martin Sjölund]

It fails on the phase after normalInlineFunction (simulation), when calculating the incidence matrix (EvaluateParameter.getParameterIncidenceMatrix).

[Martin Sjölund]

This seems to be because these parameters create a very, very dense incidence matrix.

[Per Östlund]

Fixed in ee02311a and b90d8a1. TimeTable_N_160000 (not a typo) now takes about 4.5s to pass the NF and about 2m for the backend (not including compiling the generated code).