Re: [infinispan-dev] Adaptive marshaller buffer sizes - ISPN-1102

Hi Galder Sorry I'm replying so late On Thu, May 19, 2011 at 2:02 PM, Galder Zamarreño <galder(a)redhat.com&gt; wrote: The way I see it the R algorithm is only O(n) because you have to do a random(1, i) call for each request i. Because random(1, i) tends to return bigger and bigger values with every request, the probability of actually modifying the collection of samples becomes smaller and smaller. So it would be ok to compute the buffer size estimate on every modification because those modifications are very rare after startup. Based on my assumption that modifications become very rare after startup I was thinking of using a fixed size array with a synchronized block around each access (we'd probably need synchronization for the Random, too). Note that you must use an array or a list, because you have to replace the element random(1, i) and not the smallest/greatest/something else. True, per thread statistics could remove the need of synchronization completely. But using a separate thread for doing the computations would require synchronization again, and I don't think there's enough work to be done to justify it. I totally agree, combining adaptive size with buffer reuse would be really cool. I imagine when passing the buffer to JGroups we'd still make an arraycopy, but we'd get rid of a lot of arraycopy calls to resize the buffer when the average object size is > 500 bytes. At the same time, if a small percentage of the objects are much bigger than the rest, we wouldn't reuse those huge buffers so we wouldn't waste too much memory.