Castor requires a separate SQL query to load each Object referenced by an OQL query, so it makes sense that so much of the overhead would be in the JDBC and net portions of the code (especially if your database is remote and/or you don't have a DB pool to manage connections).
In your example, Castor would need to make 1101 separate SQL queries to load all the Objects: 100 * (1 masterObj + 10 subObj) + 1 OQL query To the developers: Is there a reason why it was developed this way? It seems to me that OQL queries would be a lot faster if all the fields needed to populate an Object (instead of just the IDs) were included in the SQL composed by the OQL. Just Curious... -August --- Micka�l_Guessant <[EMAIL PROTECTED]> wrote: > I did some tests to evaluate Castor JDO overhead. > The test is a simple OQLQuery loading about 100 > master objects linked to 10 other classes. > I used Oracle 8i, Castor 0.9.4.1 and a JDK 1.4.1 > > The first results are (CPU time) : > 76.27% in java.net classes > 19.0% in Oracle Jdbc driver > 2.2% in Castor > > => We can certainly optimize Castor overhead, but > the first thing to do to improve an application > using Castor is to reduce database access by > loading only the necessary data. > > -- > Mickael Guessant > > ----------------------------------------------------------- > If you wish to unsubscribe from this mailing, send mail to > [EMAIL PROTECTED] with a subject of: > unsubscribe castor-dev > __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
