On 8/11/21 2:07 PM, clipka wrote:
> If people want precise performance metrics, anything based on a real 
> time clock - even `std::chrono::steady_clock` - is a poor choice of tool 
> anyway. In general, I would guess that the task/thread scheduling jitter 
> introduces far more noise into the measurements than the occasional 
> system clock adjustment. CPU time would be a far better candidate for 
> such things.
> 
> 
> Also note that for the purpose of performance metrics, we already 
> provide measurements of the total parsing time, both real time and CPU 
> time.
> 
> If you think we should provide more tools for performance measurements, 
> I would argue that some `#split_time` directive to print out the current 
> parser stats would make more sense than some basic building block that 
> users would have to build additional SDL code around, that in turn would 
> potentially skew the results, to actually put to use.
> 
> But I don't see any dire need for such a feature.

First, thanks for the detailed response.

I remain of the opinion POV-Ray would be better positioned with two 
'now's with a 'now_for_datetime' and a 'now_for_timing'.

A now_for_datetime can be sloppy to the order most concerns we've 
pointed out are OK. It could always use the local machine's epoch and 
local setting - aligning with other local tools in the machine/OS 
environment. Something easier for users to use date time wise.

As to timing things inside the parser. My initial reaction was similar 
to yours. The idea rattled around a while inside the cavity behind my 
eyes, and, I started to think that certain sorts of timing 
characterizations are likely simpler/better-done within the parser.

The parser, in being single threaded, is at some advantage timing wise 
for using only a one thread.

---
Something which gets asked every now and again, is whether POV-Ray could 
provide some idea as to the relative expense of certain features over 
others.

Instead of timing some block of user SDL code, imagine instead a parser 
only job which first characterizes the cost of an empty loop and - to 
the degree it can - other "wrapper" costs. We then start inserting 
things to characterize in that loop/wrapper. Single patterns in turn as 
called via functions. Functions themselves one at a time. Or trace() 
operations against base shapes/surfaces one at a time. Or particular 
parser functions one a time. Or whatever else. In many respects the 
parser can more easy isolate particular functionality than can be 
accomplished via other methods.

Imagine a large, long running, parser characterization job for all the 
'things' for which we want to track relative performance. The 
information from which we, perhaps, stick in a big table via jr's new 
macro and publish. Regular timing results useful to users and developers.

This the sort of parser timing application which I believe requires a 
more stable and dedicated 'now_for_timing'. But, yep, it's just another 
idea at this point - except for now having povr's timer specific 
f_clock() feature in hand.

Bill P.

Post a reply to this message