Performance optimization when creating the serializers #179
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We were optimizing the memory usage during start up of our application and noticed there were lots of string allocations when creating the serializers.
I profiled the BasicUsage sample in Visual Studio and 7,211,352 total bytes were allocated in 1.9 seconds (slow because the profiler was attached). After the changes in this changeset these figures changed to 1,164,024 total bytes allocated and it finished in 1.1 seconds (again, this is slower than normal because the profiler was attached), so quicker and using a lot less memory during the creation of the serializers (less pressure on the GC, which was what we were investigating in our app in general so thought I'd pass the savings on to others ).
The cause is because the
TextWriter.Nullproperty returns an internal NullTextWriter class that only overloads theWrite(string)method, meaning that anytime you callTextWriter.Null.Write("format", object)there's a call tostring.Formatwhich then gets thrown away. All I've done is generated a class that implementsTextWriterand overrides all the methods it can and does nothing in them.I've only modified the MsgPack.sln solution - there looks like there's an automated process for syncing the changes to the other solutions?