Skip to content

fix(serializer): avoid copying the whole Mapping before trimming to MAX_DATABAG_BREADTH#6783

Draft
Malkiz223 wants to merge 1 commit into
getsentry:masterfrom
Malkiz223:fix/serializer-large-mapping-copy
Draft

fix(serializer): avoid copying the whole Mapping before trimming to MAX_DATABAG_BREADTH#6783
Malkiz223 wants to merge 1 commit into
getsentry:masterfrom
Malkiz223:fix/serializer-large-mapping-copy

Conversation

@Malkiz223

Copy link
Copy Markdown
Contributor

Description

EventSerializer._serialize_node_impl's Mapping branch copied the object in full (dict(obj.items())) before trimming it down to MAX_DATABAG_BREADTH (10 by default) items. That copy is O(len(obj)), even though at most MAX_DATABAG_BREADTH pairs ever get serialized.

This mostly doesn't matter for normal extra/tags payloads, but it's a real problem for local-variable capture (include_local_variables, on by default): frame locals are whatever a function happens to hold, and it's common for self in an instance method to reference a large in-memory structure (cache, lookup table, etc). We have big caches like this in production, and capturing one as a frame local cost hundreds of milliseconds to close to a second - with a burst of such exceptions, our whole process stalled for around 30 seconds.

The fix bounds the copy to remaining_breadth + 1 pairs via itertools.islice, falling back to a full copy only when breadth is unbounded (None/float("inf"), since islice doesn't accept a float stop value). Behavior and output are unchanged - only the cost of the copy changes.

Issues

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

serialize() copies large Mapping locals in full before trimming to MAX_DATABAG_BREADTH

1 participant