Hi Holch,

holch wrote: Now if your .lss file contains data that you don't want to make accessible publicly, then go for private.

Right now there's a lot of private information in the lss file, hence marking the bug report as private.

Do you think it's worth seeing if I can upload another version of the lss file that still has the buggy behavior but that is fine to be in the public domain?

No, I don't think it is necessary. In general I think most bugs are solved by the core team anyway.

holch wrote: No, I don't think it is necessary. In general I think most bugs are solved by the core team anyway.

Ok, thanks Holch. For what it's worth, Denis suggested testing out 2.52+160929 which seems to have resolved it. Load times are around 10 seconds now which is much better!

I've also included copies of the survey running 3 different versions along with approximate loads times on my machine if this is of any relevance...

2.52+160929 - loads in 9 - 10 seconds

2.55.3+161111 - loads in about 30 seconds

2.06lts Build 160801 - loads 13 seconds

I find 9-10 seconds still quite slow, but it seems like a huge improvement over 13 or even 30 seconds.

Yeah, agreed... it may be due to a lot of survey complexity, but I'm not 100% sure...

FYI, there's a fix committed in github here ...

holch wrote: I find 9-10 seconds still quite slow, but it seems like a huge improvement over 13 or even 30 seconds.

Yep, sure.

I think we need to introduce caching in createFieldMap function but before randomization And maybe/.surely some part of EM singleton ...