exporl / apex

APEX 4: software platform for auditory behavioural and psychophysical experiments. This repository follows the major releases of APEX.
http://kuleuven.be/exporl/apex/
Other
10 stars 2 forks source link

Increasing delay between stimuli within trial over multiple experiments. #231

Closed croissanne closed 6 years ago

croissanne commented 6 years ago

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 commented 6 years ago

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

croissanne commented 6 years ago

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:

croissanne commented 6 years ago

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

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 commented 6 years ago

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 commented 6 years ago

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