2008/12/19 Oleksiy Stashok <Oleksiy.Stashok_at_sun.com>
> 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.
>
its in practical terms unlikely to become a problem.
--
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.