[Mapserver-dev] Optimizing msAddLine()

[Administrator]

It may be worthwhile to consider using David Lea's malloc/free
replacement to pick up some performance gains in the memory manager, at
least for the windows environment.

If the build for other platforms use libg++, then they're already using
this memory manager.  See http://gee.cs.oswego.edu/dl/html/malloc.html

And

http://www.cs.umass.edu/~emery/pubs/berger-oopsla2002.pdf

For some interesting discussion on this topic.

John Novak
Novacell Technologies

-----Original Message-----
From: Daniel Morissette [mailto:morissette at dmsolutions.ca] 
Sent: Monday, January 06, 2003 2:51 PM
To: mapserver-dev at lists.gis.umn.edu
Subject: Re: [Mapserver-dev] Optimizing msAddLine()


Steve Lime wrote:
> 
> Thanks David, lemme (and others?) look through the code and test it a 
> bit. Certainly looks promising though. Wonder how much affect it has 
> in web use...
> 

I think the basic idea is great (better than reallocating one item at a
time), but I'm worried a bit by the overhead in memory usage involved in
general use of the current solution, especially for things like the
labelcache that stores shapes for each label.  I could be wrong but I
would think that the majority of those shapes in the labelcache will
have only one point (i.e. one lineObj) ... so with the current
implementation we are wasting 63*8=504 bytes per label
(sizeof(pointObj)=8 on a 32 bits system).  A street level map could
easily have hundreds of labels or more, so a relatively simple street
map with 200 labels in the cache would be wasting about 100k... ...
well, now that I do the maths I guess 100k per map draw in average is
not that bad.

Anyway, what I wanted to propose is to start with a smaller buffer and
double the buffer size everytime we realloc, e.g. start with a buffer of
8 lineObj, then realloc to 16, 32, 64, 128, ... ... so assuming that
most shapes (in the Universe ;) have in average less than 8 rings we
would do only 1 allocation and not waste too much memory, and for shapes
with hundreds of rings then we would not be doing too many reallocations
(about the same number as with a fixed increment of 64).

Anyway, just a thought.

Daniel
-- 
------------------------------------------------------------
 Daniel Morissette               morissette at dmsolutions.ca
 DM Solutions Group              http://www.dmsolutions.ca/
------------------------------------------------------------
_______________________________________________
Mapserver-dev mailing list
Mapserver-dev at lists.gis.umn.edu
http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev