commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lester Ward <lw...@tagaudit.com>
Subject RE: StringBuffer pools and why not to use them
Date Tue, 18 Feb 2003 19:48:06 GMT
> However, pooling objects whose creation or initialization incur
> additional costs beyond simple memory allocation--such as database
> connections, threads, and network connections--is still a major win.

Pools are also still useful when used to optimize for something other than
speed (managing a scarce resource, for example).

> There is also evidence that pooling simply to avoid the cost of memory
> allocation provides major benefits in programs that use many threads
> running on multiple processors.

I also wonder about how the HotSpot team approaches garbage collection now.
It seems like the allocator is now really fast, but not pooling objects
seems like it would necessarily result in the GC getting called more often.
This makes me wonder what the amortized cost is. No doubt it is still faster
than pooling, but it would be interesting to see analysis on it.

Mime
View raw message