You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Has this library been tested with ToastedMarshmallow?
We have been using this library to great effect recently in a project (for about 8 months), but we're now seeing some performance hits during the Marshmallow serialization (sometimes 100's of ms) when dealing with many objects (100's)
I've seen people talk about ToastedMarshmallow and notice that the compute_schema recreates schema instances everytime, according to the ToastedMarshmallow documentation this will reduce the gain heavily.
Is there a reason we recreate schema objects every time? If not, what would be the best way to change the code to allow one schema object per resource?
The text was updated successfully, but these errors were encountered:
Ok, I see that every request may end up with a new schema based on the includes and other attributes, but when calling these from an API client there will be only a subset in use.
Caching the compute schema output would work, however the arguments will cause problems since qs and include are objects
Has this library been tested with ToastedMarshmallow?
We have been using this library to great effect recently in a project (for about 8 months), but we're now seeing some performance hits during the Marshmallow serialization (sometimes 100's of ms) when dealing with many objects (100's)
I've seen people talk about ToastedMarshmallow and notice that the compute_schema recreates schema instances everytime, according to the ToastedMarshmallow documentation this will reduce the gain heavily.
Is there a reason we recreate schema objects every time? If not, what would be the best way to change the code to allow one schema object per resource?
The text was updated successfully, but these errors were encountered: