Oops - my test case is obviously miscounting the recursion. The depth
of recursion is not the issue.

There were 2000 insert/commits and then one select for the 2000 records.
Each record had 10 string fields. getStringProperties was called 40K
times and allocated 480K blocks of memory for a total of 16962K. The
number of allocs and number of bytes was much higher than any other
function in this simple test.

The property it is getting is isc_dpb_lc_ctype. Call stack:
ClumpletImpl.find
FBConnectionRequestInfo.getStringProperties
FBManagedConnection.getIscEncoding
FBConnection.getIscEncoding
FBStringField.getIscEncoding

Which is actually called each time FBStringField.getString or
FBStringField.setString is called. I can imagine that setString and
getString are called pretty often in almost everyone's applications.

Each time we set the string field - the code is searching through the
clumlets and then converting the bytes into a string. Perhaps you want
to have a getString() method of clumplet that keeps a cached version of
the string in memory. Or perhaps you want to take a look at setString
and getString and optimize with the assumption that each statement
executed will probably use multiple calls to set/getString.

FYI: The profiler is numega and the JDK is 1.4.