Open gmanvel opened 8 months ago
That's a brilliant idea Manvel and actually one of the directions that I was investigating some time ago.
I was trying to build the whole expression tree based on the resolvers results and have it invoked at the very end of read/write operation.
What is needed in your opinion to get to that point?
Ideally, your GetMethodCall()
method would be replaced with regular ResolveWriter()
invocation and have the current paths covered. Could you maybe create a branch with your code that we could work on together?
@AdrianStrugala I pushed the changes described in the issue to perf/improve-record-resolver branch. As for expression tree approach to resolve writer for objects, let me get back to you after I spent some time thinking about it.
Describe the solution you'd like
While profiling the application for memory footprint, I noticed a lot of boxing allocations
Note, that highlighted
Guid.ToString()
allocations will be removed once #133 is merged. As highlighted, there are a lot of allocations for value types (Guid, boolean, Int64, Int32). I think this is due to boxing that takes place in dynamically compiled lambdaGenerateGetValue
. In a nutshell it doesSo, all value types returned as object will be boxed which we can see from the profiler. The code that is used to profile:
Looking into
User
,Contact
,Offering
classes, they indeed haveint
,long
,bool
,Guid
properties. It would be good to remove these box allocations and improve memory footprint ofAvroConvert
Describe implementation idea
The idea is to instead use dynamically compiled lambda which will write each property value using corresponding
IWriter
method.WriteRecordFields
method will becomeAction<object, IWriter>
represents a compiled lambda which avoids boxing allocations and corresponds to roughlyWhich could be achieved by a similar expression builder (I did not handle every possible property type, rather made sure this will cover
User
,Contact
,Offering
model properties)Running same profiling code with this approach eliminates boxing allocations
Additional Context
I appreciate that this is quite a refactoring which makes changes to the core of the library, nevertheless wanted to share my findings.