Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MultiThread: Fix initial period prediction in multithread mode #1628

Merged
merged 1 commit into from
Jan 16, 2025

Conversation

peaBerberian
Copy link
Collaborator

While checking why some tests on #1627 didn't pass I realized that this was due to an actual real performance issue in multithread mode in rare scenarios.

Basically, the WorkerMain module - whose role is to setup everything worker-side in multithreaded mode - gives a hint of what could be expected to be the first Period to load in the content.

However, it always gave the first Period - I guess we put a placeholder when first writing the code and forgot to replace it until now.

As this is only a hint, this doesn't really led to any important issue, the only visible problem - and why some integration tests failed sometimes - were that the actual module relying on that information took some time (the next playback observation so from 0 to 1 second) before correcting the value.

In very specific scenarios, this could mean loading 1 second later than usual (this wasn't really visible on initial load here but it happened in tests for RELOADING cases).

While checking why some test on #1927 didn't pass I realized that this
was due to an actual real performance issue in multithread mode in rare
scenarios.

Basically, the `WorkerMain` module - whose role is to setup everything
worker-side in multithreaded mode - gives a hint of what could be
expected to be the first Period to load in the content.

However, it always gave the first Period - I guess we put a placeholder
when first writing the code and forgot to replace it until now.

As this is only a hint, this doesn't really led to any important issue,
the only visible problem - and why some integration tests failed
sometimes - were that the actual module relying on that information took
some time (the next playback observation so from 0 to 1 second) before
correcting the value.

In very specific scenarios, this could mean loading 1 second later than
usual (this wasn't really visible on initial load here but it happened
in tests for RELOADING cases).
Copy link
Collaborator

@Florent-Bouisset Florent-Bouisset left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@Florent-Bouisset Florent-Bouisset merged commit 169e6d6 into dev Jan 16, 2025
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants