retrieveConditionInfo in qanda.php does a db query for every field, which could make things slow. Better would be to do 1 query, save the resulting array and filter out the qid you need by looping. This way a lot of db queries van be saved improving the speed.

To identify all the queries executed, edit the mysql to activate query log. This would be the best start I think as just inserting all fields should not be much of a problem.

It definately is a problem if there are 1000+ hidden fields in every page loaded.
Besides that it is a unnecessary waste of ressources.

I would expect that to be a problem for javascript execution, looping over all input fields and page rendering in the browser, not really on the server side. Aren't all fields in the session anyway? If we could get our hands on the problem survey we could do some profiling to see where the problems are. Although I do agree resources should never be wasted.

I think long surveys and conditions have always been an issue and we did various things to improve speed in the past. Maybe we can use a survey from an old topic to check. I remember one that had many pages of arrays with filters that got slower and slower while you got more towards the end of the survey.

One recent thing added is using tokens in condition. If the problem survey doesn't use that, but does use tokens, it could be a nice start to rule out the newly added token feature by disabling tokens and seeing what performance does then.

I did a fix to the array filter which caused a lot of unneeded repetition. Commited the fix in 9964 for bug 04787. Please check if this is still an issue.

Thomas, is this still an issue with the expresison engine?

Carsten-

This is still somewhat of an issue. I was planning to do smart embedding, but have not gotten there yet. Right now, all substitutions are written to the page both from PHP (so that the starting values are correct), and as JavaScript-based substitutions. This is instantaneous for Firefox and Chrome, but causes a second delay per navigation event in Internet Explorer. So, the plan is to only create JavaScript substitutions for items that can actually be dynamically changed on the page.

As to the database query issue, my hope is to see CreateFieldMap() re-designed to do a single DB query to popuplate everything $fieldmap('full') needs and store it in $_SESSION, including the answers.

EM will prevent the need for the long queries for getting Conditions, once we remove Conditions (or as long as people don't use them).

Lastly, for performance, we might want to add Relevance as a field in the Questions table so that I don't have to retrieve it from QuestionAttributes, but that isn't currently a problem, since we almost always have to get QuestionAttributes anyway, so I just create some relevance-related $_SESSION[] variables.

This is no longer an issue in 1.92.
Conditions are no longer read at run-time, so that slow-down is eliminated.
Although qanda does query the DB for every question (something that will be fixed in a plus release or 2.x), Conditions were the biggest source of slow-down.

1.92RC2 released.