[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