RFC-24: published implementation proposal on bugzilla

Steve Lime Steve.Lime at DNR.STATE.MN.US
Mon Mar 5 14:55:28 EST 2007


Wow, thanks for all your hard work on this (and Tamas with all the feedback). Is there any
performance hit with the reference counting and dynamic memory allocation? And if so, can
it be quantified?

Steve

>>> On 3/4/2007 at 9:46 AM, in message
<75b4b93e0703040746v129adf71ya36c185b4ac98f46 at mail.gmail.com>, Umberto
Nicoletti <umberto.nicoletti at GMAIL.COM> wrote:
> I have been working on an example implementation of rfc-24 and the
> fruit of my labor is attachment #632 to:
> http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=2032 
> 
> Direct link:
> http://mapserver.gis.umn.edu/bugs/attachment.cgi?id=632&action=view 
> 
> Apply this patch to cvs HEAD to see how rfc24 would be implemented.
> The patch only modifies the map and layer objects, the rest is still 
> unmodified.
> 
> Key points:
> 1. refactor map->layers to be an array of pointers instead of a array of 
> structs
> 2. allocation of a new layerObj only happens when needed, thus conserving 
> memory
> (allowing for large values of MAX_NUM_LAYERS with minimal waste of memory)
> 3. wrap map->layers access with GET_LAYER macros to ease future developments
> (i.e. removal of MAX_NUM_LAYERS)
> 4. check that layer->map is not null before using it and raise a new
> error if it is (MS_NULLPARENTERR)
> 5. reference counter for mapObj and layerObj
> 6. modification of mapserver core and swig interface files to do reference
> counting for map and layers (incr and decr)
> 7. created unit tests for python (mapscript/python/tests/cases/refcount.py) 
> to
> test the functionality of the previous items. This has not been added to
> runtests.py yet
> 
> Due to the large extent of the changes I have also made available
> items 1,2,3 and item 4 available as two separate patches.
> 
> Happy hacking and tell me what you think,
> Umberto



More information about the mapserver-dev mailing list