Hello, did some benchmarks here [1] too for caching array allocations. Its indeed faster to cache and recycle them (from a relative point of view) but in absolute figures allocating a 512k byte array on my machine is about 100 microsec (= 0.0001 sec), a typical 8k bytebuffer is created within 2 microsecs, which is IMHO not really a bottleneck. In spite of that i created a alternative to BufferCache which doesn't deal with threadlocals but deals with different buffer sizes. Please see BufferRecycleCache.java [2] for details. Implementation is unsynchronized by default but can be used synchronized by using BufferRecycleCache.synchronizedBufferRecycleCache().
To be honest i don't know what the best way to go. For the sake of simplicity i would prefer to allocation cache at all. What do you think? Thanks Hendrik [1] https://github.com/salyh/fleece_tmp/blob/benchmark-bufferrecyclecache2/fleece-core/avg_benchmark_jmh_result_f1_t4_w3_i4.txt https://github.com/salyh/fleece_tmp/blob/benchmark-bufferrecyclecache2/fleece-core/src/test/java/org/apache/fleece/core/jmh/benchmark/BenchmarkBufferRecycleCache.java https://github.com/salyh/fleece_tmp/blob/benchmark-bufferrecyclecache2/fleece-core/src/test/java/org/apache/fleece/core/jmh/benchmark/BenchmarkBufferRecycleCacheStateSynced.java [2] https://github.com/salyh/fleece_tmp/blob/benchmark-bufferrecyclecache2/fleece-core/src/main/java/org/apache/fleece/core/BufferRecycleCache.java https://github.com/salyh/fleece_tmp/blob/benchmark-bufferrecyclecache2/fleece-core/src/main/java/org/apache/fleece/core/ByteBufferRecycleCache.java (Implementations for char[] and StingBuilder are analogue) On Fri, Jun 27, 2014 at 5:09 PM, Romain Manni-Bucau <[email protected]> wrote: > Hi > > there are 2 BufferCache usage. Basically we cache *allocations* (not > values) of StringBuilder and char[] (parser buffer). Name is maybe not the > best one, BufferRecycle can be better. Fleece factories are thread safe, > (then parser, generator etc are not). > > It really changes the performances but a better implementation (with no > dependency) would work. > > Any proposal? > > > > > Romain Manni-Bucau > Twitter: @rmannibucau > Blog: http://rmannibucau.wordpress.com/ > LinkedIn: http://fr.linkedin.com/in/rmannibucau > Github: https://github.com/rmannibucau > > > 2014-06-27 16:22 GMT+02:00 Hendrik Dev <[email protected]>: > >> Hello, >> >> what is the main purpose of org.apache.fleece.core.BufferCache<T>? >> >> Is it to be a real thread local cache (because we excpect that we have >> many parallel threads running) or just a cache which use threadlocals >> as a kind of an internal implementation (not expecting really parallel >> threads)? >> >> The comment within this class is >> "// alloc are expensive so using a very trivial buffer, we remove from >> TL to say we use it and reset it when we are done (close)" >> Which allocations are meant? StringBuilder, char[], <T>, ... >> >> Is fleece supposed to be a threadsafe library? (Beyond wahts marked to >> be thread-safe in the apispecs) >> >> Thanks >> Hendrik (salyh) >> -- Hendrik Saly (salyh, hendrikdev22) @hendrikdev22 PGP: 0x22D7F6EC
