Hi Gustav,
I completely agree with your concerns.
>
> The possibility of minor performance improvements here comes with
> the price of currently unhandled risks.
>
> The cost of new instance should be compared to :
>
> cometContext.recycle() cost. clearing structures out with their is
> not a 0 cost.
> ensuring a max cache size.
> the cache handling in general has overhead handling its own
> concurrent datastructure.
> check of individual cometcontexts data structure sizes, should an
> context that had 1000 handlers be cached, whats the probability
> that the next topic need that ?.
> possible use of weak / soft references can help regarding the memory
> usage (this is perhaps not needed here , just a general
> consideration for all kind of caches )
If we use cache, with limited size like BlockingQueue classes - it
means we always pay synchronization cost.
The caches, where we don't limit the size at all - are faster (like
ConcurrentLinkedQueue), but here we come to possible problems with
uncontrollable cache growing.
I don't know details about CometContext complexity and amount of
memory we allocate for it. But for sure it's worth to be investigated.
WBR,
Alexey.
>
>
> the total overhead for the cache management must a analyzed to be a
> known win situation,
> even if it is analyzed to be a win , is it large enough to make
> the extra complexity worthwhile ?.
>
> --
> your servant
> gustav trede
>
> coding is art - not only something that bring food on the table,
> everybody should be able to feel proud about their code,
> that they have performed their best considering the given conditions.
>