Too many garbages that can be collected.
pcfulife opened this issue · 5 comments
Detailed Description
All IChroma APIs are async which creates Task objects. On profiling my app, allocating objects are too many when I turn on Razer Chroma function.
Context
These allocated objects make app stuttering. (Chroma operates at 60 fps)
Possible Implementation
Provide not async but sync version API. Or, making a blocking collection that is used by one thread and enqueue to this.
Thanks.
Providing synchronous APIs (again) is something I've been wanting to add as well. Currently the question is how to implement it nicely due to HttpClient (used for the REST API) does not have a sync version of the Send method available in .NET Standard 2.1 (it was added for .NET 5.0).
Possibly we can multi-target Colore and call and use a dirty version of SendAsync().GetAwaiter().GetResult() on standard, and use the proper one in .NET 6.0.
The native SDK would be possible to use properly sync under both targets of course.
Have you or are you able to run tests with the native SDK switched to using ValueTask instead of Task? Does it make any noticeable difference?
@pcfulife There's a new branch (feature/sync-apis) with sync versions of the APIs added. You could try it out and see if it solves some of the issues (note that sync APIs will not work for the REST API unless you're on .NET 6.0 since HttpClient doesn't have very good support for sync APIs currently).
You can also get a NuGet package from the GitHub feed: https://github.com/chroma-sdk/Colore/packages/274021?version=7.0.0-sync-apis0223
@Sharparam Oh, Thanks a lot. I will try it.
@Sharparam It works perfectly even I use .NET Core 3.1
Good to hear! The synchronous API should work on all platforms. It's only the synchronous HTTP that would be an issue to get working since there is no good support for that in .NET (when using the new HttpClient).
But I reckon people who are using the HTTP API would not be as likely to want a synchronous API anyway.