Re: [lmi] Remarkable performance problem

[Vadim Zeitlin]

On Thu, 2 May 2019 00:06:03 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2018-02-28 23:59, Greg Chicares wrote:
GC> > [...replying to the message that started the thread in the hope of
GC> > preserving some semblance of threading--I haven't received copies
GC> > of my own more recent messages from the list server...]
GC> > 
GC> > On 2018-02-28 01:54, Greg Chicares wrote:
GC> > [...]
GC> >> Today Kim sent me a census file that runs quickly enough for her, but
GC> >> shockingly slowly for me.
GC> 
GC> A similar problem occurred today, with a different '.cns' file from
GC> actual production. This census has 1233 cells. Elapsed time for
GC>   Census | Run case
GC> by build:
GC>   772996 msec gcc-7 32-bit
GC>   235816 msec gcc-8 32-bit
GC>   133271 msec gcc-8 64-bit

 Just to get a feeling how bad the problem is, would it be possible to know
how long does it take with the native Linux version on the same machine?

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

 The latter could be explained in some handwavy fashion, but I really have
no idea why would the compiler upgrade result in such dramatic improvement.

GC> > I suspect that running the first 100 or 200 cells depletes some
GC> > scarce resource.

 Again, I just don't see how is this possible because the computation code
shouldn't consume any resources managed by Wine. The only remotely
plausible candidate I can think of is something used by the progress
display, so I wonder if disabling the progress meter could speed up the
process?

 Sorry for still not having been able to profile this myself (to be honest,
I've totally forgotten about it as I somehow didn't have it in my TODO
list). I'll try to do it, but please let me know if the problem is serious
enough to warrant bumping it up to the top of my TODO queue.

 Thanks,
VZ