-
-
Notifications
You must be signed in to change notification settings - Fork 72
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
Variant memory allocations #184
Comments
That will not be easy to fix (if it is fixable at all). So the same code as for reading anything else on the message is used to get that header information. I'll take a closer look to that, maybe I can refactor some points to get rid of the overhead of creating variant objects. |
Alright, after hours of investigating, optimizing and refactoring I added a new branch with my changes. The change will use a new method to read the header for each message which will not create the |
Thank you! The In our main application, the Preliminary application tests show significant improvements: there are far fewer stop-the-world events now. We're basically back to pre-D-Bus integration performance. Much appreciated. |
After resolving #182, instances of
Variant
now dominate memory profiling, as shown in the screenshot:The GC profiling shows:
Is there anything that can be done to reduce the number of
Variant
instances created? There appears to be a 1:1 relationship with aMessage
instance.The text was updated successfully, but these errors were encountered: