Andrea Aime a écrit :
> First I noticed there were no indexes on the db, and created them, then
> noticed a few queries may haven't been optimal, but go only a handful of
> seconds improvements (around 6 seconds improvement over 2 minutes...)
Good idea. We need to keep trace of the index creation however, if we don't
want to lost them the
next time we will update the EPSG database (the database provided in epsg-hsql
is supposed to be
created from the SQL scripts downloaded from the EPSG site).
> My profiling now tells me that the most frequent call we do is a query
> to compute the number of axis in a crs. Unfortunately this query is not
> buffered by the buffering wrapper class (that is meant to cache results,
> right?) and thus the very long time to perform queries.
Yes, the buffering wrapper class is supposed to cache the results.
The axis were not cached because I was unhappy with the method signature used
in FactoryUsingSQL,
namely:
createCoordinateSystemAxis(String code, final int dimension)
All other methods expect only a (String code) argument, and I though that the
above signature should
not exists in a public API. However, if profiling show that it is a performance
botleneck, we can
make a compromise. This method would need to be public or at least protected
because
BufferedAuthorityFactory is in a different package. I will do this change and
see what performance
we can get (will try to keep it protected).
If you could fix the suboptimal queries on your side (problems in SQL
statements I presume?), that
would be appreciated :).
> Another thing I've noticed is that prepared statements don't get reused.
> Bad, this is another place were we can shave off significant seconds depending
> on the database (I don't know how hsql behaves, caching and reusing
> prepared statement gives a definite performance boost on both Oracle and
> SAPDB).
The prepared statement are supposed to be cached by FactoryUsingSQL too. There
is a
private final Map<String, PreparedStatement> statements = new
IdentityHashMap...
field in the class. If the statements are lost, then there is probably a
problem (except that the
code is designed for closing all statements after some timeout, which is 30
minutes by default).
> Maybe we could concentrate on speeding it up instead of removing tests?
> That would require some kind of internal axis number cache (maybe a flag
> stating that the database is immutable and thus can be freely cached).
I will try to cache the axis and see what I get. Thanks for yours insight,
Martin.
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
