All,

Ok, I've been profiling the JCA-JDBC driver with JProfiler(tm). I've
received some very interesting results. I'm going to get right down to it.
Methodology will be listed at the end of this message. NOTE: This is for
select statements only.

What I found was that 61% of the *time* was spent in the
java.lang.String<init>(byte[], int, int) constructor. And the method
calling this constructor? org.firebirdsql.jgds.GDS_impl.parseTruncSQLInfo.
This is because it is filling the XSQLVAR classes String objects. 68% of
the time was spent in the parseTruncSQLInfo method.

So good news, and bad news. I'm looking through the code now to determine
what kind of dependancies we have on those fields being strings as opposed
to byte arrays. I bet there will be quite a dependancy there because the
Strings are public. I'm not sure if there is a WHOLE lot that can be done
here since that data needs to be loaded into memory, and I don't think
Strings are very heavyweight. Therefore, it might be a moot point.

However, since 68% of the execution time of a select statement is in this
method, it wouldn't hurt to see if it can be optimized in any way. I'll
look it over, but since it isn't commented very well the guru's might want
to take a look at this.

Rich


Methodology:

First off, the only thing this application is doing is running the following
sql statement against the employee.gdb database:

"select * from employee where emp_no = 141"

I then go into this *very* tight loop

for (int i=0; i<numLoops; i++) {
rs = s.executeQuery(sql);
}

where numLoops is something big like 100000

So, the profiling that was done is for select statements, and nothing else.
Pretty simple.


_________________________________________________________________
Join the world�s largest e-mail service with MSN Hotmail.
http://www.hotmail.com