Re: [lmi] Remarkable performance problem

[Greg Chicares]

On 2018-02-28 23:59, Greg Chicares wrote:
> [...replying to the message that started the thread in the hope of
> preserving some semblance of threading--I haven't received copies
> of my own more recent messages from the list server...]
> 
> On 2018-02-28 01:54, Greg Chicares wrote:
> [...]
>> Today Kim sent me a census file that runs quickly enough for her, but
>> shockingly slowly for me.

A similar problem occurred today, with a different '.cns' file from
actual production. This census has 1233 cells. Elapsed time for
  Census | Run case
by build:
  772996 msec gcc-7 32-bit
  235816 msec gcc-8 32-bit
  133271 msec gcc-8 64-bit

I have gcc-7 and gcc-8 in different debian "buster" chroots,
both of which have the same "wine-4.0 (Debian 4.0-1)". They were
created in exactly the same way; the only difference is that the
gcc-8 one has been apt-upgraded a little more recently.

It seems reasonable to hypothesize that the problem is wine,
and it's less severe with gcc-8, and still less severe with
64-bit lmi.

> There would seem to be something about that file that causes
> difficulties with 'wine'. The reported symptoms are greatly
> mitigated by either of the following changes:
> 
> (1) Simply save the file, then close and reload lmi, and load
> the saved file.

That trick doesn't seem to make any difference with this file.

There was a trick (2) [snipped], which I didn't bother trying
today because the "worst symptom" below doesn't seem to be
present in this case, yet the "performance deteriorates"
issue is present.

> Anyway, even if we figure out why modifications (1) and (2)
> above treat the worst symptom (making the GUI so unresponsive
> that simply closing lmi takes longer than XFCE expects, so it
> pops up an "lmi has stopped responding" messagebox), another
> issue remains: performance deteriorates during a census run.
> I.e., "Census | Run case" pops up a progress dialog which,
> after the first hundred cells or so are processed speedily,
> estimates how long the command will take to complete, but
> that estimate grows and grows. With either (1) or (2), with
> an empty $WINEDEBUG, an early estimate of about 65 seconds
> grows to about 360 or 380 by the end. I haven't yet ruled
> out the possibility that the later cells are more difficult
> to process, but that seems unlikely; I suspect that running
> the first 100 or 200 cells depletes some scarce resource.

What I observe today is similar. With the least-bad gcc-8-64bit
build, the progress meter estimates a total of forty-one seconds
after the first few cells, and that 40000 msec grows to 133271.

It seemed curious that the estimated time remaining was almost a
constant twenty seconds through most of the run. I was trying to
think of this as a calculus problem, hoping it would lead me to
some grand insight involving 'e', but 133 sec wasn't enough for
me to solve it.