Increasing delay between stimuli within trial over multiple experiments.

[croissanne]

When a trial has multiple stimuli, delay between those stimuli increases when doing the experiment multiple times without shutting Apex down between experiments. This delay can be significant (>250 ms per experiment) depending on the stimuli.

This was observed by sending out simple clicks in the stimuli, whereby time between clicks increased within a trial.

[croissanne]

Data gathered during avatar experiments: avatar-delays.xlsx, 'delay multi' tab is relevant here.

[croissanne]

Due to extensive logging in StatusReporter. Maybe also other factors, but this seems to be a major culprit at least.

The avatar experiments log quite a bit of data (all parameters being sent to unity) through the parametermanager. Each time an item gets added rendering/resizing etc... has to happen.

Suggestions:

• Rate limiting QAbstractItemView::scrollToBottom
• QTableView::resizeColumnToContents only on item click?
• test avatar with 'QT_LOGGING_RULES="*=false"'
• no multiline items in StatusReporter => all rows the same height
• prevent misuse of logging window, maximum length equal to tweet length; no restriction in ErrorHandler which goes to console
• avatar remove extensive logging

[croissanne]

So I tested the avatar experiment with the following changes to the ScreenStatusReporter:

• Maximum length for messages.
• No newlines allowed.
• Rate limit scrollToBottom, limit of once per 250ms.
• Only resize columns when a message exceeds the maximum recorded length of a message.

Time between 2 stimuli within 1 trial	seconds
First experiment after apex start, statusreporter shown, debug level enabled	5.5
First experiment after apex start, statusreporter hidden, debug level enabled	5.4

Artificially populated the StatusReporter (with about 20 experiments worth of output on debug level)	difference between 2 stimuli within 1 trial seconds
With changes, statusreporter shown, debug level enabled	6.5
With changes, statusreporter shown, debug level disabled	5.5
With changes, statusreporter hidden but debug level enabled	6.5
With changes, statusreporter hidden and debug level disabled	5.5
==========================================	====
Without changes, statusreporter shown, debug level enabled	6.5
Without changes, statusreporter shown, debug level disabled	5.5
Without changes, statusreporter hidden and debug level enabled	6.5
Without changes, statusreporter hidden and debug level disabled	5.5

To be honest I'm a bit baffled by these results, I would have thought hiding the StatusWindow would reduce the performance hit and that the changes made would at least have some impact. The only thing that matters is quantity and whether the level is enabled.

When a level is disabled each item belonging to that level is explicitly hidden. When I explicitly hide each item when hiding the StatusReporter, it's 5.5s, regardless whether or not the debug level is enabled.

[croissanne]

Setting unformRowHeights to true (missed that one :grimacing:) seems to bring it down to 5.5 with debug level enabled.

I'll remove the rate limiting of scrollToBottom and remove the maximum length for messages since they have little to no effect.

No newlines obviously stays, and only resize columns when a longer message is recorded seems sensible.

[croissanne]

I think this issue got mostly fixed in the latest patch related to ScreenStatusReporter.