shapeObj buffer resize algorithm

[Kovacs Baldvin]

> However, I am finding it hard to imagine it making a significant
> difference in mapserver.   You mention that your test case as
> "having pretty much lines".  Are these features with a single
> line, or with many lines in one feature?  I would have thought 
> that multi-line line features would be relatively uncommon in 
> general use.  Polygons with holes might be much more common,

Well. The thing is, in my application there are lots of multilines.
And I did not do scientifically correct measurements as of yet, 
but good point, I'll do, and sent them to the list.

> at a time.  If we used realloc() the runtime library would have the
> opportunity to recognise that the underlying allocation block
> is actually larger than needed, and that no transfer is actually needed.
> I am not sure how widely this sort of optimization is implemented in
> libc implementation but it seems like it *ought* to already be embedded.

Good point too. I'll include the bufsize += 1 "heuristic" in the
measurements.

> I am somewhat concerned by your optimization because it now means
> anywhere that creates a local lineObj needs to remember to 
> properly initialize the bufsize array.  You may have found and updated

Hey, but I don't accept this. If one chooses not to use a correct 
object-oriented style, than one has to take the consequences. If 
you take either gtk or cichlid, they are both C language projects,
but they follow very very strict rules so that every object has 
constructor functions, member acces functions, everything. In mapserver code
there are 4 of 5 lines of code for every construction of a shapeObj
object. It means that it is already a problem, this bufsize patch
does not make things qualitatively worse, just quantitatively.
I don't like to rely that much implicitely to some maybe-present
optimisation feature... However, well, OK, I accept that pragmatically
it is better not to introduce bufsize because of ist possible effect
to user libraries. However, interface changes must happen --- and
wrong interfaces are subject to more painful changes, users must
know it, and programmers must admit it.

Actually I've checked where I need to introduce a "bufsize =" line
by grepping for numlines, and picking the lines where numlines was
set, not just read. But as of yet, I did not descend to subdirectories.

I'll come back if I have measurements... and hope that the simple change
to realloc in itself will do a good job.

Best regards,
Baldvin