Interesting...

I don't think the recursion itself is a problem, but the depth of 50 makes
me suspect there are several copies of a lot of parameters in the clumplet
list. I also doubt the replacement of our custom linked list with a
hashset would offer noticable improvement.

Storing everything as a byte array was to make it very easy to write to the
output stream.

Maybe a better approach is to store both an object representation of the
object and a byte[] rep. in each clumplet, or to get the byte[] from the
object.

Did your measurements indicate if this took a noticeable percentage of the
time, or was it just a large fraction of the allocation calls?

Thanks!!
david jencks

On 2002.10.17 14:04:26 -0400 Ken Richard wrote:
> I am new to optimizing java so perhaps I can learn a little bit. I may
> be picking out items that may have no "real" impact on performance.
>
> I ran the code (that was posted on this thread) through a profiler and
> noticed that one of the top memory-allocators was the function
> org.firebirdsql.jca. FBConnectionRequestInfo.getStringProperty. The
> function appears to be called once for each request sent to the
> database.
>
> public String getStringProperty(int type)
> {
> if (c == null)
> {
> return null;
> } // end of if ()
> if (c.find(type) == null)
> {
> return null;
> } // end of if ()
> return new String(c.find(type));
> }
>
> c is a ClumpletImpl. Here is the find function (hacked to show the
> depth of recursion):
>
> public byte[] find(int type)
> {
> return find(type,0);
> }
> private byte[] find(int depth, int type)
> {
> if (type == this.type)
> {
> System.out.println("yes-depth:" + depth);
> return content;
> } // end of if ()
> if (next == null)
> {
> System.out.println("no-depth:" + depth);
> return null;
> } // end of if ()
> return next.find(depth + 1, type);
> }
>
> Now - it appears that the function getStringProperties is getting called
> once per database request. For each request it does a recursive search
> (depth 50 on my test). If the value is found - the search is performed
> twice and a new string is allocated for each time a property is
> retrieved.
>
> Question 1: Would the getStringProperty be better implemented as a
> HashMap of Integer-to-CLumpletImpl objects?
>
> Question 2: Would there be an advantage of caching the string allocated
> in the HashMap instead of caching the ClumpletImpl in a HashMap?
>
>
>
>
> To unsubscribe from this group, send an email to:
> Firebird-Java-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>
>