fwiw, I did the following in SQLHelper
public static Object getObjectFromColumn(ResultSet rs, FieldDescriptor fld) throws
SQLException
{
if (fld.getColumnIndex() == -1)
{
fld.setColumnIndex(rs.findColumn(fld.getColumnName()));
}
return getObjectFromColumn(rs, fld.getColumnJdbcType(), fld.getColumnIndex());
}
as a very easy way of using the name to resolve the index only once, and then use the
index from then on. the performance tests showed almost 0% improvement. However this
could be a per-driver performance issue.
I have not removed the hashmap row that is used during buildWithReflection and
replaced it with a directly indexed array, indexed by ColumnIndex in the
fielddescriptor yet. I will try that and see if their is a performance gain.
cheers,
Matthew
-----Original Message-----
From: John M [mailto:[EMAIL PROTECTED]
Sent: Fri 6/27/2003 2:57 PM
To: [EMAIL PROTECTED]
Cc:
Subject: question about performance - cache, pre-fetch, other
I'm using rc4 from cvs with the PB kernel only.
During testing of a piece of the application I had
some pretty serious performance problems as a whole
lot of data is being read at once. Most of the object
model I have has auto-retrieve on and everything is
proxied via interfaces.
The first pass at the code had no optimization, so
running through a list of, say, 1000 objects
potentially caused 1000 * 3 single queries as
referenced objects were forced to load by accessing
the proxy. Obviously not good. One way to fix this
perhaps is to have the global cache and just hope that
all the objects are in there when references are
resolved so it's faster.
What seems to be the OJB way is to use the prefetched
relationships in a Query. However, this didn't seem
to work great for my problem for a couple of reasons.
One is that it selects with an IN clause, which is
limited in size. So really for a lot of results you
may have several queries. I also don't know how fast
mySQL can be expected to return a query when you pass
it 100 ids in an IN list, either. A big one, however,
is that you can only prefetch one reference deep as
far as I can tell. So if you have A->B->C, you can
prefetch B when querying on A, but you can't get C.
My solution was to change OJB to allow the following:
select the fields from all the tables (objects) you
want loaded and retrieve the data in one query,
building the objects from there. My question is this:
Does this sound valid and useful, or am I missing
something or totally off my rocker? For the way we
are using OJB this seems to fit the bill perfectly
when used appropriately.
Here's how I changed OJB to support this:
Added a query type that holds the reference names to
get (and allows OJB to know you want to do it that
way)
In SqlSelectStatement it appends all the columns
from each table specified. This is a little different
that what normally happens in that fields from
ClassDescriptor.getFieldDescriptors are used directly
instead of getFieldDescriptorsForMultiMappedTable
because the order is important. This is the part most
likely to screw something up, but we don't use fancy
mapping.
Changed SqlQueryStatement to forcibly add table
aliases for the desired join tables in case they
weren't specified in the Criteria.
Modified RsIterator, RowReader, and
RowReaderDefaultImpl to allow reading of a row into an
object given an offset and FieldDescriptor array.
This should be a little faster anyway as it reads
based on the index instead of name, but being able to
use the offset is the most important thing.
Modified RsIterator to read and cache the extra
objects from the joins as it iterates through the main
object list. These are read before the main object so
the references in the main object resolve to the
cached objects.
I just submitted a couple of other patches to the dev
list that I found while looking at this stuff, but
they seemed more generic and thus could stand alone.
I can submit patches for these changes if anyone wants
to see them. Hopefully this or something like it will
be worked into OJB so I don't have to keep track of
these changes!
Thanks,
John Marshall
Connectria
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
