Just stepped through the code, so I can now give a definite answer:

* POV does indeed release memory occupied by any #define'd thing the very moment
it is #undef'd (rested for a #define'd mesh2; I presume the same holds true for
#local's, and other types of data).

* After parsing and before rendering, POV implicitly #undef's everything.

* Re-#define'ing a thing implicitly #undef's the old content, too.

Note that this is true even for objects that have been "invoked" someplace; this
is possible because such "invocations" actually create a copy. (Some "bulk"
objects like meshes share data between copies, but lifetime of this shared data
is governed by a reference counter.)

So the benefits of #undef I see are as follows:

- Improve parsing speed by keeping the identifier table small (might be an issue
if the number of identifiers significantly exceeds about a hundred, at which
time the 257-entry hash table will start to get "saturated")

- Keep memory footprint as low as possible during parsing

- Avoid potential pitfalls when different parts of the scene file happen to use
the same identifier

I think these apply mainly to macro suites: You never know how many other
memory-hungry, identifier-rich macro suites may be used alongside yours in a
scene file; for instance, any non-#local variable used to temporarily hold an
array to resize it should be #undef'd immediately after use, and any non-#local
variable holding a building block for a complex CSG should be #undef'd as soon
as the complete object is assembled.

On the other hand, especially for macro suites, even better than using #undef is
using #local wherever possible.

For an actual scene file, I think the cases where use of #undef will save your
day are rather scarce. E.g. If you do a lot of array resizing, you'll probably
re-use the same temporary variable anyway, or even use a macro to do the job.

Post a reply to this message