Survey tool response is slow


1. Log in the Survey Tool
2. Select Language (in our case Croatian)
3. Select any page from the left panel
4. click button to vote for Winning value
5. keep voting on the same page (Starts to slow down after 1 votes)
Actual: The orange background on each item voted builds up until the tool become unresponsive and freezes (screenshot shown).
Chrome translates to – "Page unresponsive, please wait or close the page"






Thomas Bishop
June 30, 2020, 1:00 AM

It’s clear that some inefficiency in the JavaScript or CSS is resulting in “Forced reflow while executing JavaScript took…” but it’s not clear yet what it is. Maybe something in bootstrap, jquery, or dojo, but it could be in our own code (js or css). I’d still like to figure that out and fix it.

Thomas Bishop
June 30, 2020, 12:47 AM

postpones handleChangedLocaleStamp, which is what triggers an all-row WHAT_GETROW request, if the request queue has multiple requests pending. It postpones if queueCount > 1. It might also work to postpone if queueCount > 0, at the cost of sometimes postponing longer than ideal, given that the attempt won’t be made more often than every 15 seconds.

Idea for further improvement – see comment I added here:

Maybe we could compute a quick checksum of the json data for each row, and save those checksums in the json or a related data structure, and skip updating the rows whose checksums match the data already in the table. That should save a lot of time for all-row getrow.

Thomas Bishop
June 29, 2020, 5:53 PM

On Chrome, I can prevent any “violations” from exceeding 1 second during fast voting by disabling the all-row getrow request, which is normally on a timer that fires every 15 seconds. That is, by disabling this line in survey.js:

This isn’t an ideal solution, since the all-row getrow request is needed, sooner or later, to ensure that rows are updated to reflect votes by other users (as well as warnings/errors that involve interactions between two or more rows).

Still, evidently the worst slow-down during fast voting occurs in this way. The all-row request, and/or the DOM update that occurs when the response is received, should be postponed until updates for votes have been completed. Eventually we should optimize the performance of the DOM updates, but I don’t see any easy way to do that yet.

Thomas Bishop
June 26, 2020, 4:25 PM

The Chrome console reports some very interesting “Violations” when there are several orange rows:

Thomas Bishop
June 26, 2020, 3:18 PM

The png issue on Chrome turns out to have been user error on my part: Chrome has an option to disable the cache when DevTools is open, and either it’s on by default or I checked it by mistake.





Thomas Bishop


Kristi Lee


Mark Davis



Fix versions