-
Notifications
You must be signed in to change notification settings - Fork 720
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
Optimize new tracing system #3763
Comments
@jutaro, you can use the following targets for perf comparisons:
This will provide the results in:
|
The number of messages put into the tracing system is very high. In this test in one node more then 2 million messages are send. This results in some processing and allocation overhead, even when all messages are filtered out. Here are profiling entries that are shown in an chainsync-early-byron run:
We see that at least 6,3% of processing goes into tracing and > 13% of allocation. In reality these numbers will be higher. |
We added a new maybeSilent combinator, which switch off any message of a particular tracer based on the configuration. If the configuration gives a value of
The maybeSilent combinator is put by default as the first filter in the tracer build by
The drawback of this, is that metrics is suppressed, if it is send by a tracer that has been silenced. In the generated documentation you can find by which tracer a metrics gets send. |
With an optimized solution in which metrics are not filtered by maybeSilent we get:
This means computation is reduced from 6,3% to 3,6(2,4)% and allocation from 13% to 5.2(3,2)%. The numbers in parenthesis are from the solution above, which as well filters out metrics for silent tracers. |
Closing this. If this is still relevant please reopen. |
Use profiling to find out ways to optimize the new tracing for minimal CPU, Memory and GC load.
The text was updated successfully, but these errors were encountered: