Memory traffic in Formatter
StasPerekrestov opened this issue · 5 comments
Hello,
I've been profiling an application I'm working on and found out that
LogFormatter causes some significant memory pressure.
If you don't mind I'm going to create a PR with some ideas for your review.
Thanks for the contribution. I've updated the code further to reuse the StringWriter throughout the entire batch down to the log template rendering. This should eliminate many of the string allocations and improve performance. Can you test out the latest commit to see if it works for you? I'll release a new version afterwards.
Thank you @manigandham
Going to test your changes the next morning. :)
Ok, some results. I haven't created an appropriate benchmark yet, but what I can see so far:
If we take MessageTemplateParser.ParseTextToken as our allocation base, then before changes we had
R = 9816700/10536766 ~= 0.93
After your recent changes this rate has become:
R = ~0.95
which confirms that there are some improvements.
There is another source of excessive allocations and it resides in Serilog core project.
Moreover, this
Serilog.Parsing.MessageTemplateParser.ParseTextToken(Int32, String, Int32) method also performs
lot's of Substrings.
I've played a little bit with MessageTemplateParser to make it use ReadOnlyMemory instead of plain String, but it may require some significant refactoring.
To sum up, thank you for your changes :)
Sounds good, I'll release an update with these changes then.
The changes have been released as version 2.4.0, closing this issue now.
https://www.nuget.org/packages/Serilog.Sinks.GoogleCloudLogging/2.4.0