Skip to content

Conversation

@timkaechele
Copy link
Contributor

@timkaechele timkaechele commented Sep 28, 2025

Problem

If the buffer is nearly full even one extra character can trigger an expansion of the buffer. Since the buffer only grows by twice the number of required characters per resize, in this case 2 characters, the buffer has to be constantly resized.

Visualization

buffer_problem

How the problem is addressed

Rather than just checking the required length, we test whether doubling the current capacity will be enough. If it is, we expand to the doubled capacity. If not, we double the required length itself and resize the buffer to that size.

Performance impact

Lexing a real world html page

Before: ~88.255ms

After: ~79.208ms

Parsing showed no significant performance impact though

Copy link
Owner

@marcoroth marcoroth left a comment

Choose a reason for hiding this comment

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

Thanks @timkaechele! 🙏🏼

@marcoroth marcoroth changed the title Implement more efficient buffer resizing C: Implement more efficient buffer resizing Sep 30, 2025
@marcoroth marcoroth merged commit 5bbd4d9 into marcoroth:main Sep 30, 2025
13 checks passed
@timkaechele timkaechele deleted the efficient-buffer-resizing branch September 30, 2025 06:45
asilano pushed a commit to fac/herb that referenced this pull request Oct 21, 2025
## Problem

If the buffer is nearly full even one extra character can trigger an
expansion of the buffer. Since the buffer only grows by twice the number
of required characters per resize, in this case 2 characters, the buffer
has to be constantly resized.

### Visualization


![buffer_problem](https://github.com/user-attachments/assets/11658cf7-1ab5-41fe-8a75-fc6eaddfb80a)

## How the problem is addressed

Rather than just checking the required length, we test whether doubling
the current capacity will be enough. If it is, we expand to the doubled
capacity. If not, we double the required length itself and resize the
buffer to that size.

## Performance impact

Lexing a  [real world html page](https://shop.herthabsc.com)

Before: ~88.255ms

After: ~79.208ms

Parsing showed no significant performance impact though
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants