[Mapserver-dev] MAXLAYERS, MAXSTYLES, MAXCLASSES all that necessary ?

[Daniel Morissette]

I think the main reason why it's not this way yet is that nobody has
taken the time to tackle this.  I agree that this would be a very
welcome enhancement, perhaps if this one makes it in the next release
then that would be enough to call it version 4.0.   ;-)

I have filed a bugzilla enhancement about this, let's continue the
discussion there:
http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=302

BTW, there was a thread on mapserver-dev talking about a method to
increase the array of points in a lineObj dynamically, the same
technique could also be applied here as well:
http://mapserver.gis.umn.edu/wilma/mapserver-dev/0301/msg00024.html

Daniel



Attila Csipa wrote:
> 
> On Thursday 27 March 2003 18:21, Daniel Morissette wrote:
> > > #define MS_MAXLAYERS 1000 /* maximum number of layers in a map file */
> > Is this really an intentional change?  This can have a quite significant
> > impact on memory usage.
> 
> While we are at it, I'd like to ask why isn't this solved ina semi-dynamic way
> ? We all know that the issue of insufficient layer/class space keeps popping
> up in the lists, but I'm not sure why it has to be done this way.
> 
> If there has been a discussion about this I'm sorry for bringing it up again.
> 
> If I'm correct the problem is here:
> 
> int initMap(mapObj *map)
> {
>   map->numlayers = 0;
>   if((map->layers = (layerObj *)malloc(sizeof(layerObj)*MS_MAXLAYERS)) ==
> NULL) {
>     msSetError(MS_MEMERR, NULL, "initMap()");
>     return(-1);
>   }
> ...
> 
> So if MAXLAYERS is high, we're mallocing huge amounts of data. My question is,
> why is this better then mallocing a fixed amount (which would be, say, the
> current MS_MAXLAYERS value), and then when/if we fill up this space just do a
> realloc on a new layer init (this could be done by duplicating allocated
> space and not simply increasing so overhead of both processing and memory
> would not be significant). This way there would be only a memory limit on the
> number of layers and classes, while the loss of speed would be insignificant
> (advanced users could still change the initial number of layers, in which
> case there would be practically no slowdown).
> 
> Regards,
> Attila
>