Thomas, do you have a quick idea on this?

Does the same problem happen in 1.92? To the best of my knowledge, the LEMrelXX functions were specifically designed to only be called for questions that have some dependency upon others - whether in relevance, validation, or tailoring. There were some limitations - such as questions having array filters, that had to always be called, but beyond that, I did try to minimize the number of calls.

I don't have an easy way to test -- other than a production website, I haven't done anything with LimeSurvey in over a year, and don't have a computer on which it is installed.

abezverkhyy, does this happen with 2.0 or 1.92, too?

Exact same behavior on LimeSurvey 1.92. See the screenshots attached.

Please also attach a screen-shot of the "Show Logic File" for those two questions. It appears that Q7 uses array_filter from the previous question to specify which sub-questions should appear. I found that it was necessary to call check_conditions for all sub-entries within array_filter in order to properly handle cascading array_filter (cases where Q3 was filtered on Q2 and Q2 was filtered on Q1).

So, although it might be possible to reduce the number of calls to check_conditions, doing so in this case could break the accuracy of the conditional logic.

Two suggestions:
(1) Although the debugger shows 1.5 seconds for each call, it will be faster wit the debugger off.
(2) Internet Explorer 8 is notoriously slow with LimeSurvey. Chrome and Mozilla both run 5-10 times faster than Internet Explorer 8 on the same survey.

I just attached the output from "Generate Logic File". Notice that nothing uses Q7 in its expression, but any event on Q7 trigger thousands of reevaluations.

(1) this is not true, with or without the profiler, I can easily count to four seconds before any form element reacts, and I have a pretty good machine, imagine what it might be on low-end hardware.

(2) I agree, but you don't usually know the people who will take your survey and you can't force them to install browser X or Y, sadly IE8 is still used by something like 10% of Internet users.

I understand that some events might always remain slow on IE8 as its JS engine lacks performance, but what I'm pointing out in this bug report is that the generated JS code might be doing lots of useless reevaluations which is an algorithmic issue.

The source of the issue is that the question group has a condition. A group condition is bool-added to the condition of each question and re-evaluated on each action.

TMSWhite, do you remember why you did that? If a group is already displaying I think it makes not much sense to re-evaluate it over and over in each action inside the group?

A workaround might be to have smaller groups. But I did not check that.

I believe that was needed to ensure accuracy in cascading array filter exclude (bug #06087). You can test this using some of the demosurveys, like https://github.com/LimeSurvey/LimeSurvey/blob/master/docs/demosurveys/ls2_cascading_array_filter_exclude.lss

I think that in group-by-group or all-in-one mode it would have been better to create a group container element that is under EM control.

That would even cover the twisted 'group condition base on a question inside its group' scenario and could be applied even to question-by-question mode.

IE11 still is somewhat slow but alot better.

for further references, the UsesVars list is generated here in this loop:

https://github.com/LimeSurvey/LimeSurvey/blob/master/application/helpers/expressions/em_manager_helper.php#L7205-L7325

to be more precise, here:
https://github.com/LimeSurvey/LimeSurvey/blob/master/application/helpers/expressions/em_manager_helper.php#L7317

and seems correct

First impressions:

I can be wrong, but it seems that the problem is this one:

in survey_runtime.js, function checkconditions we have:

if($.isFunction(window.ExprMgr_process_relevance_and_tailoring ))
{        
    ExprMgr_process_relevance_and_tailoring(evt_type,name,type);
}

The function checkconditions is called for each "onchange" event of each question.

If one question has relevance, the function ExprMgr_process_relevance_and_tailoring will exist, so the condition will be true for all questions, so it's called each time you click on a question, whatever is the question...

So, a way to fix this would be to replace the condition by something like:

if (any question depends on the question clicked)
then
ExprMgr_process_relevance_and_tailoring

Fix committed to master branch: http://bugs.limesurvey.org/plugin.php?page=Source/view&id=20218

Fix committed to master branch: http://bugs.limesurvey.org/plugin.php?page=Source/view&id=20220

Fix committed to master branch: https://github.com/LimeSurvey/LimeSurvey/commit/f48151539a7bc5ad5cc012a9f446981b51b7374e

Isn't this one fixed?

I have to do the last part of it.
I will do it next week.

bump

Fix committed to develop branch: http://bugs.limesurvey.org/plugin.php?page=Source/view&id=24910

Looks like this fix causes this regression: https://bugs.limesurvey.org/view.php?id=12980

yep

Small amendment, we had to exclude equation questions from the filtering.
This is because it may be that an equation question is directly dependant on another equation question.
Due to the selective reevaluation this leads to the issue that the second line equation question is not reevaluated and thus stays at the old value.
This has been done in commit a9daeeabbdaeaacaa19f0c94f7ed60b00a3b7691