Elsewhere, during the discussion related to the 'now' keyword, I floated
the idea of using the parser with povr's f_clock() as a way to measure
the relative cost of various keywords, patterns, shapes and functions.
Using Tor Olav Kristensen's array statistics include as updated for v3.8
and jr's Tabulated() include (thank you both!), I've got an initial pass
of some timing test code going.
In the attached image the rows above the null row are measuring the cost
of calling things from the parser itself. Of note, the f_null() function
is close to the simplest inbuilt function possible. All it does is
multiply a single passed float by 0.0, returning zero. In that row I'm
trying to gauge the relative cost of the call from the parser to any
inbuilt function - the overhead for the function call itself.
Below the null row measuring the cost of some functions as if they are
being called from within the vm. Closer to the isosurface / parametric
relative cost.
Aside: Because timing was done with a version of the povr branch with
the extra debugging and assertions turned on, the cost of the var()
parser function is inflated. I added a chunk of extra assertion and user
debug-aid code there - and it's active.
Bill P.
Post a reply to this message
Attachments:
Download 'timingstory.jpg' (256 KB)
Preview of image 'timingstory.jpg'
|