[Proj] Optimizing lookup of init files
Daniel Morissette
dmorissette at mapgears.com
Wed Aug 1 08:49:20 PDT 2007
Hi,
Users of applications such as MapServer that make use of the
"+init=epsg:4326" type of syntax to initialize projection definitions
have reported a performance issue when their maps contain multiple
projections (see http://trac.osgeo.org/mapserver/ticket/1976).
After discussing the issue with Frank it seems that the best fix would
be to implement caching in the get_init(), get_defaults(), and get_opt()
functions which manage access to initialization files for +init
statements and for defaults.
Unfortunately implementing caching in a static data structure could
introduce some multi-threading issues for some applications. There are
two possible ways to handle this in a thread-safe way and I would like
to get your opinion on which one you think is best:
Option 1:
---------
Implement multi-threaded locking support to protect the blocks of code
that deal with the cache. We would likely do this using a copy of the
code from MapServer's mapthread.c/.h which supports Linux (Pthreads) and
Windows and has been tested and is known to work on several platforms.
For more details on this option see the documentation starting at line
30 in mapthread.c:
http://trac.osgeo.org/mapserver/browser/trunk/mapserver/mapthread.c
Option 2:
---------
Create the concept of a pj_session data structure in which we maintain
the cache and can which be easily extended later on to contain any
relevant information that needs to persist between various calls to the
PROJ API.
Then we could create a pj_init_ex.c with
pj_init_ex(pj_session *, int argc, char **argv)
which calls get_init_ex(), etc...
To maintain backwards compatibility, the existing pj_init() and family
would simply be calls to the pj_..._ex() equivalent with a NULL session
handle. If the session handle is NULL then no caching happens.
The pj_session object would be created and freed using
pj_session_create() and pj_session_destroy() by the calling application
if it cares to take advantage of caching and other persistent features.
There are pros and cons to both approaches. Can anyone think of a 3rd
option that would be even less disruptive?
Comments and suggestions welcome. I'm especially interested in feedback
from developers of applications using PROJ.
Thanks in advance
Daniel
--
Daniel Morissette
http://www.mapgears.com/
More information about the Proj
mailing list