Skip to content

Conversation

@JohannesLorenz
Copy link
Collaborator

This adjusts the performance test due to liblo's commit

4899a0d9653a347ee25cf5013ebddc615b1ef80f

The rtosc code was requested to stay as it is - i.e. to still allow messages not starting with /.

Also, this changes Windows build to take Release, which gets around the (still existing) liblo issue where the Debug execution of performance hits the assertion

Assertion `d.matches == 3600000' failed.

(which causes infinite test execution on Windows due to failed assert). Using Windows Release build allows us to run the performance test with liblo 0.32.

This adjusts the `performance` test due to liblo's commit

4899a0d9653a347ee25cf5013ebddc615b1ef80f

The rtosc code was requested to stay as it is - i.e. to still allow
messages not starting with `/`.

Also, this changes Windows build to take Release, which gets around the
(still existing) liblo issue where the Debug execution of `performance`
hits the assertion

```
Assertion `d.matches == 3600000' failed.
```

(which causes infinite test execution on Windows due to failed assert).
Using Windows `Release` build allows us to run the `performance` test
with liblo 0.32.
@fundamental
Copy link
Owner

Two things per the assert, shouldn't a failed assert result in a non-zero exit code and ctest saying 'failed test' on that platform? Secondly, it's concerning if the number of matches is different on that platform as it indicates the dispatch logic does not behave there.

@JohannesLorenz
Copy link
Collaborator Author

Two things per the assert, shouldn't a failed assert result in a non-zero exit code and ctest saying 'failed test' on that platform?

This is an ancient problem with Github Actions on Windows. IIRC we never found out why the asserts keep the build run forever, and it might be hard to debug this. We might still try by using a debugger on tmux.

Secondly, it's concerning if the number of matches is different on that platform as it indicates the dispatch logic does not behave there.

Agreed, this should be fixed. This is an ancient problem on our side though, and totally independent of this PR's issue.

@fundamental
Copy link
Owner

Fair points. I'm running the test locally now and assuming it works as intended this should be merged in about 15 minutes.

@fundamental
Copy link
Owner

Looks like this creates non-matching behavior on the rtosc side, so I'm fixing the test. Current results in release mode match debug mode (but of course with better release performance):

Matches: 3600000 vs expected 3600000
RTOSC Performance:     0.12 seconds for the test
RTOSC Performance:     29.46 ns per dispatch
LIBLO Performance:     1.41 seconds for the test
LIBLO Performance:    352.20 ns per dispatch

@fundamental
Copy link
Owner

Merged via 0e91f0c

@fundamental fundamental closed this Oct 2, 2025
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.

3 participants