Measure

[O-Pelumi]

Add cpu time measurement functionality for user defined functions and predicates.

[mity]

Hello @O-Pelumi .

I took a look what you are working on. I appreciate your interest, I also acknowledge that some kind of time or CPU cycle measuring would be beneficial, but at the same time, to be honest, I do not like much the direction where this goes, so please let me elaborate on it a bit.

The main issue I see is the macros introduced here are in one way very limited: They measure the duration of the argument itself. For any non-trivial things this means you usually may need to isolate the measured code in a function of its own if it is not just a one-liner.

(I also do not like much the names of the macros, but that is detail, and I do not have anything better right now, so lets keep this aside for now.)

Therefore, let me to provide the following counter-proposal. Or actually two proposals but they could play nicely together:

1. Report test unit duration time automatically: Probable makes only sense for successful test units, so those could write something like "[ok] (duration: XXXYYY), where XXXYYY would be some human readable information about the time/CPU cycles taken.

2. Additionally, if the test implementer wants to really measure some smaller amount of work then the whole unit test, I would probably prefer sort of macro(s) which would not take the work to do and measure as its argument. And they would measure the time since start of the unit test, or the most recent use of the same macro in the given unit test. This would allow to measure even longer multi-line code snippets without the need to isolate them in an extra function or something like that. Or alternatively they could be two macros for starting/ending the measured code snippet.

Feel free to comment whether this could satisfy your needs and/or argue why your approach is better.

[O-Pelumi]

Hi @mity

Thanks for the feedback, I've actually come to see the same pitfalls with hindsight and your points are very valid. Points 1 and 2 are well noted and will be put into consideration in my subsequent attempts.

Nice library by the way, simple and easy to use.

Regards

[mity]

Sorry, I won't merge this.

• After a lot of thinking, I think allowing o measure arbitrary code parts leads to too bogus interface and output.
• clock() is very problematic, because it can be quite imprecise and systems even differ what it means. For example on POSIX systems it should mean CPU time, on Windows it is real clock time.

Instead I implemented something different what measures duration of complete unit tests, and what tries to use some high-precision timers if available, and (on POSIX at least) user can choose whether he wants real time or CPU time.