On Dec 22, 2010, at 9:05 PM, Maurice LeBrun wrote: > A cautionary note: PL_MAXPOLY impacts a fair amount of code. Also there are > heap-vs-stack performance implications -- e.g. directly moving from a fixed > allocation to a malloc/free each time plfill() is called could suck for the > many small-n-vertices polygon case. Using per-stream polyline buffers is > better but more convoluted. The short term solution is definitely just > recompile with a higher limit.
How about alternate versions of these functions that allow the caller to provide (via a pointer) the "workspace buffer"? That would place the onus of malloc/free on the caller, but would also allow the caller to decide how to handle memory allocation failures as well as reuse the same workspace buffer for multiple calls. "We" could even provide a "plpoly_alloc" function that would take "convenient parameters" (e.g. npts) from the caller, compute the buffer size required, allocate a buffer of that size, and return the resulting pointer (or NULL if the allocation failed). The existing implementations of plfill et al. could simply call the new alternate versions passing in pointers to their statically allocated buffers. Just an idea, Dave ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
