• Post Reply Bookmark Topic Watch Topic
  • New Topic

StringBufferFactory  RSS feed

 
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have a few classes that use many StringBuffers. I was considering the creation of a StringBufferFactory and instead of instantiating a new StringBuffer, these classes could:
StringBufferFactory sbf = new StringBufferFactory ( int );
... code ...
StringBuffer sb = sbf.getStringBuffer();
... do stuff with the StringBuffer ...
sbf.returnStringBuffer ( sb );
I have a VectorFactory and DBConnectionFactory that perform similar functions and have achieved significant performance and scalability improvements, and was wondering if this would be worth one's while to do.
Thanks,
onlyOOD
 
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Oops - partial post, see next one.
[ August 06, 2003: Message edited by: Stan James ]
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
To be real nit-picky I'd probably call those things Poolers instead of Factories, but if they work it matters much less what we call em.
Connection pools are a very common way to improve performance. In fact, pooling is built into many drivers these days. Are you sure your JDBC provider doesn't already do pooling? If not, having your own was probably a good idea.
Since you've done two already, can you see how to generalize a pooler that could hold anything? My project uses one we copied out of a magazine. It will hold a fixed number of any object. If you ask for an object and the pool is empty it blocks the thread until one is put back in. With such a generic pooler in hand, you could do real-life benchmarks to see if pooling StringBuffers helps.
I'd have to say it just might. EJB containers pool EJB objects for reuse just to avoid creating and garbage collecting them too often. Maybe you'll get the same benefit.
 
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Connection pools - absolutely, those are useful. StringBuffer pooling? I really doubt it. Making a new StringBuffer is just not that expensive. And most of the expenst comes from allocating a new char[] array - this would happen anyway with pooled StringBuffers, any time you call toString() and then change the StringBuffer contents. More troubling, once you force a StringBuffer to increase the size of its char[] array, it will never decrease; only increase. (In current implementations anyway.) Which means that once you've supersized it by creating one really big String, that memory will never be reclaimed, even if the String is GC'd and you only use the StringBuffer for really tiny strings for the rest of its life. (Well, "that memory" may be reclaimed, but only because the StringBuffer is recopying its contents to another char[] with is at least as big as the one it's abanconing.) Using a fresh new StringBuffer() whenever you need one makes it much easier to ensure the StringBuffer isn't taking up far more memory than you need. StringBuffers are lousy candidates for reuse, for this reason.
And from the Book of Joshua, Chapter 2, Item 4 (p. 16):
Conversely, avoiding object creation by maintaining your own object pool is a bad idea unless the objects are extremely heavyweight. A prototypical example of an object that does justify an object pool is a database connection. The cost of establishing a connection is sufficiently high that it makes sense to reuse these objects. Generally speaking, however, maintaining your own object pools clutters up your code, increases memory footprint, and harms performance. Modern JVMs have highly optimized garbage collectors that easily outperform such object pools on lightweight objects.

Lastly, Vectors are just plain evil. Icky old APIs with usually-needless synchronization that is probably in the wrong place if you really do need synchronization. Use ArrayLists instead. And the same arguments apply as for StringBuffers - they get bigger, never smaller. Just Say No to Vector, Hashtable, and Enumeration, unless you have no choice.
 
Rancher
Posts: 13459
Android Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jim Yingst:
And from the Book of Joshua, Chapter 2, Item 4 (p. 16)

Your first question in any situation should always be "What would Joshua do?".
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!