Skip to content
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

ReflectiveTypeAdapterFactory.BoundField.write memory overhead #2321

Closed
sembseth opened this issue Feb 20, 2023 · 2 comments · Fixed by #2325
Closed

ReflectiveTypeAdapterFactory.BoundField.write memory overhead #2321

sembseth opened this issue Feb 20, 2023 · 2 comments · Fixed by #2325

Comments

@sembseth
Copy link
Contributor

Problem solved by the feature

Reduced memory allocation when serializing data.

Feature description

Whenever a BoundField is written a new TypeAdapterRuntimeTypeWrapper is constructed. As far as I can tell the TypeAdapterRuntimeTypeWrapper could just as well be constructed as a final variable outside of the write method. When re-using Gson instances this will reduce the total amount of memory allocated during serialization.

gson_memory_overhead

@Marcono1234
Copy link
Collaborator

Thanks! This looks like a good suggestion, do you want to create a pull request for this?
I assume if serialized == false there would also be no need to create the TypeAdapterRuntimeTypeWrapper then if it is not used anyways.

@eamonnmcmanus
Copy link
Member

I wasn't completely convinced at first: if we construct the TypeAdapterRuntimeTypeWrapper outside the anonymous BoundField then we save having to construct it inside, but on the other hand we have a bit more memory being used all the time versus just inside BoundField.write. But actually I see that there are three local variables captured in createBoundField just so that they can be used in this one line: typeAdapter, context, and fieldType. That means three hidden fields in the anonymous subclass. If we construct the final TypeAdapter just once then that is just one hidden field, assuming we also use it in the readIntoArray and readIntoField methods. So I think the extra memory is pretty small.

In short, thank you for the idea, and I agree with @Marcono1234 that a PR would be welcome.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants