Skip to content

Conversation

@mesram
Copy link
Contributor

@mesram mesram commented Nov 8, 2025

The buffer automatically grows when capacity is exceeded (as indicated by the comment in the initialiser), so by definition .count can never exceed .capacity. And since buffer growth is likely exponential, it's highly unlikely that they would ever be equal.

@sliemeobn
Copy link
Owner

sorry for the delayed review.

even though I am still not 100% happy with how the chunking works, this looks a lot "more correct" that what I had before. so: thank you!

I feel there should be some way to

  • use spans
  • allocate very, very little
  • don't exceed chunk-sizes somehow without a big performance hit

but that will be an exercise for a different day ; )

@sliemeobn sliemeobn merged commit f60224d into sliemeobn:main Nov 11, 2025
7 of 8 checks passed
@mesram
Copy link
Contributor Author

mesram commented Nov 12, 2025

Awesome! No worries on the timeline, I'm honestly surprised you got back to me so quickly.

I've just been exploring Swift on server casually (well...hoping to convince work to let me use it in places) now that it seems a lot more mature and got really excited to see a library that meshed perfectly with my idea of how this stuff "should" work (I am needlessly frustrated by the waste in the Javascript ecosphere). Got pretty confused when it didn't seem to stream out like it looked like it should have, I legitimately thought it might have been a Hummingbird issue lol, or that I just didn't read the manual well enough. Was far too pleased when I got it to work and then streamed out 500MB of HTML while the server sat cooly at its 4MB baseline, and crashed the browser xD

@mesram mesram deleted the bugfix/async-renderer-buffer-check branch November 12, 2025 13:49
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.

2 participants