Tapestry Training -- From The Source

Let me help you get your team up to speed in Tapestry ... fast. Visit howardlewisship.com for details on training, mentoring and support!

Wednesday, September 28, 2005

Lots of small objects ... or too many?

I was very interested in the post Object Count Impact on Garbage Collection Performance. As someone who tends to work using large numbers of small objects, I do have a concern in the back of my head about crossing over the line ... especially in light of the slower startup speed of Tapestry 4 (on top of HiveMind) vs. Tapestry 3.

In fact, the article jives well with my thinking; Slobodan's minimum object count map (which he promises to discuss in later blog entries) may likely look like the class I have yet to write ... a very, very simple Map implementation tuned for a small number of keys and a very, very, very high ratio of reads to updates ... the kind of thing that, say, stores attribute values for an XML entity (something used all over HiveMind). I was thinking about using an Object[] array at the core, with alternating keys and values.

Meanwhile, I still think the general approach I take is the right one ... and the reason I can't ever go back to a non-garbage collected language. I like breaking problems into tiny pieces and getting emergent behavior by combining the tiny pieces into more complicated wholes. From an efficiency standpoint, Tapestry is doing the right thing by caching entire pages (not components within pages, which would be more of a JSP tag model). But Tapestry does use an awful lot of HashMaps.


Neil Swingler said...

How about the jakarta commons Flat3Map:

Anonymous said...


Yep, that is more or less what I am doing. Keep coming back and you'll get the finished product.

And thanks for the link :)


Anonymous said...

Jakarta Commons - Collections provides read optimized implementations of List and Map. The relevant classes are FastArrayList, FastHashMap, and FastTreeMap

from the javadoc for FastArrayList -
A customized implementation of java.util.ArrayList designed to operate in a multithreaded environment where the large majority of method calls are read-only, instead of structural changes.