Campbell's tests in the past have helped focus the development effort into areas that need improvements most. These new tests are no exception.
Following some internal discussion and tests by Karl, I have been concentrating this week on reengineering some of the core classes that are responsible for type conversion and are used in every area of database operation. These conversions take place when the statement is parsed, arithmetic operations performed, rows saved internally in memory or cached tables, ResultSet creation, ResultSet translation to objects with getXXX methods, in short, everywhere. I focused on optimising conversions to (a) use direct conversion between types instead of turning them into Strings and creating new Objects based on the String and (b) reading and writing types in a binary format in ResultSets. The fact that far fewer temporary objects are created will improve speed both at the time of execution AND garbage collection. It would also reduce the load on memory so that larger ResultSet can be created. I have nearly completed the above and will have an internal perview of RC4 available in a couple of hours for anyone who wants to test it. (this is not for general release so please ask for a copy if you can spend some time testing it). The next step is to use the new data structures for persistent storage in *.data files (cached tables). Fred ----- Original Message ----- From: Campbell Boucher-Burnet To: [EMAIL PROTECTED] Sent: Saturday, April 06, 2002 1:42 PM Subject: [Hsqldb-developers] On The Subject Of Prepared And Callable Statements: So once again, the conclusion I keep coming to (a conlusion stated on Road Map in a post of mine showing experimentally that ~ 60% of statement processing time for the standard test script is spent in the parsing phase, with ~20% in actual update, and another ~20% spent in logging) that the single best and 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, for longer running statements, we will still need to introduce optimization of query execution and possibly multithreaded execution for better throughput under a mix of long and short running transactions...but that is a ways off and requires a complete rearchitecting, whereas there are many things we can do right now to improve parse performance. All comments and suggestions welcome. Cheers, Campbell _______________________________________________ hsqldb-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hsqldb-developers
