rschmitt commented on PR #578: URL: https://github.com/apache/httpcomponents-core/pull/578#issuecomment-3548134623
@ok2c I'm going to ask one or two more qualified people for an opinion and get back to you. My understanding is that object pooling _can_ outperform garbage collection, but it's harder to do than you'd think. (There's also the question of what "outperform" means. What are we measuring, tail latencies? CPU overhead? Heap footprint?) Pooled buffers also come with a lot of risks, like increased potential for memory leaks, or security vulnerabilities such as buffer over-reads. The Javadoc says that the `PooledByteBufferAllocator` is inspired by Netty's pooled buffer allocator, but which one? In Netty 4.2, they [changed](https://netty.io/news/2025/04/03/4-2-0.html) the default allocator from the pooled allocator to the `AdaptiveByteBufAllocator`. What does that mean, exactly? `¯\_(ツ)_/¯` Evidently it may have something to do with virtual threads. I guess the main concern I have here is the effectiveness of adding buffer pooling _retroactively_, compared with the cost in code churn. Typically what I see is frameworks or applications that are designed _from the ground up_ to be garbage-free or zero-copy or what have you. I think this proposal would be more persuasive if I knew what we were measuring and what our performance target is, and what the hotspots currently are for ephemeral garbage. Can they be addressed with a _minimum_ of API churn? (I find it's very difficult to thread new parameters deep into HttpComponents; if we implemented pooling, I'd prefer to make it a purely internal optimization, and an implementation detail. We should be more hesitant to increase our API surface area.) Finally, I think it's a little late in the development cycle for httpcore 5.4 to be considering such a change. Any usage of pooling in the HTTP/2 or TLS or IOReactor implementation should probably be gated behind a system property and considered experimental. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
