I think we may be talking past each other.
I believe you are envisioning a usage model when all the SQL is executed from a script. That is an important model and you may be correct about that usage model. Another way to use HSQL is from within a java application or JSP. In that case you can connect directly to the db engine and take advantage of JDBC. I think in that case prepared statements have a *lot* of value. There is no need to use "CALL" then. > First, a CALL must be made to prepare the statement, > saving it on the server under a handle (say CALL > prepare(sql) returns int), then another CALL must be > made to execute the prepared statement (say CALL > execute(int) returns Result). As such, the call to > execute the prepared statement must itself be > parsed, Check out the API for java.sql.PreparedStatement http://java.sun.com/j2se/1.4/docs/api/index.html The parser is called *once*, when the PreparedStatement is first constructed in the Connection.preparedStatement After that simply set the parameters and call executeQuery(). Implemented correctly, PreparedStatement.executeQuery() should be list of atomic operation on the db. Each operation is an object which supports an exec( ) function. Just go over the list and excecute each operation. This would be ideal for a threaded web server app that must connect to the db and execute a small set of queries with a few parameters over and over. It greatly reduces the overhead of parsing to almost nothing. > performing a CALL uses Java reflection to match the > procedure name with a java.lang.reflect.Method, I dont see the need for using Reflection at all if we use PreparedStatement. >As you can see, the overhead currently associated >with parsing and executing a "CALL" statement ruins >any benefit obtained by accessing a prepared >(precompiled) select statement, even a moderately >complex one. >~ 60% of statement processing time for the standard >test script is spent in the parsing phase, Ouch! that whole thing can be optimized away. At least when you in a JSP or Java application with a simple set of queries. >with ~20% in actual update, >and another ~20% spent in logging We should have more fine grain control of logging. >most direct way to improve the over-all performance >of the hsql database engine for short-running >statements is to really focus mostly on speeding up >and making the parser more efficient, if possible. Of course this is good goal. ===== Karl Meissner ........................................................... : Meissner Software Development, LLC : : "Software development and project management services." : : http://meissner.v0.net/resume.htm : ........................................................... __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ _______________________________________________ hsqldb-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hsqldb-developers
