Hello Rich, > Although MINA probably *uses* buffers for short periods of time, wouldn't > it > be possible to make the underlying buffers "long-lived" by pooling them > between usages? Of course, if we pooled buffers then we'd need to support > some mechanism of returning the buffers to the pool (probably an explicit * > free* or *dispose* operation).
Memory is long-lived as is and the OS operates it "good" when the JVM requests some. I don't see a reason to move memory allocation from the OS to the application. This will only increase complexity (a need for free(), accidentally disposed buffers that are still needed, maybe high memory consumption of our single mina process in an environment that may need every free byte of memory urgently etc.) and I'm not convinced that there will be a noticable performance gain at all. > To me, the question of whether or not its worth the bother of doing this > comes down to the following questions: > - is there any performance benefit of using direct buffers? All I know about direct buffers is from the docs. Logically thinking, the bytes in direct buffers must reside somewhere in non-JVM memory and can be mapped to the JVM to avoid copying - and this makes it good e.g. for explicitly mapping file contents to memory for fast access before saving it back to disk (avoid IO operations). When working with network interfaces, I don't see a possibility to improve performance. I think all the buzz about direct buffers is from its naming as being "direct" which sounds good somehow ;). As always, I may be wrong...so feel free to correct me. regards Daniel
