Skip to content

Conversation

@karlseguin
Copy link
Collaborator

Rather than stack-allocating MAX_MESSAGE_SIZE upfront, we now allocate 32KB and grow the buffer as needed for larger messages, up to MAX_MESSAGE_SIZE.

This will reduce memory usage for drivers that don't send huge payloads (like playwright does).

While not implemented, this would also enable us to set the MAX_MESSAGE_SIZE at runtime (e.g. via a command line option).

Copy link
Contributor

@sjorsdonkers sjorsdonkers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, any specific reason for why the number 32 was chosen?

@karlseguin
Copy link
Collaborator Author

32KB for the default buffer? No. Any suggestions?

@krichprollsch
Copy link
Member

I think we can be more conservative and use only 16kb to start.
the max we have if I ignore playwright with our e2e test is ~10kb

Rather than stack-allocating MAX_MESSAGE_SIZE upfront, we now allocate 32KB
and grow the buffer as needed for larger messages, up to MAX_MESSAGE_SIZE.

This will reduce memory usage for drivers that don't send huge payloads (like
playwright does).

While not implemented, this would also enable us to set the MAX_MESSAGE_SIZE
at runtime (e.g. via a command line option).
@karlseguin karlseguin force-pushed the dynamic_cdp_read_buffer branch from 1417280 to efc983b Compare August 29, 2025 02:34
@karlseguin karlseguin merged commit 431db85 into main Aug 29, 2025
10 checks passed
@karlseguin karlseguin deleted the dynamic_cdp_read_buffer branch August 29, 2025 04:21
@github-actions github-actions bot locked and limited conversation to collaborators Aug 29, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants