shapeObj buffer resize algorithm
baldvin at CS.ELTE.HU
Wed Jul 27 04:55:20 EDT 2005
> 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
> 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.
More information about the mapserver-dev