On 09.02.25 19:10, John David via Discuss wrote:

That's not going to work. OpenSCAD is not a procedural programming
language, so having a measure built-in is not possible.

I think the solution would be annotating the generated geometry
with the data and finding a way of showing that to the user in a
reasonable way.

Long story short. There is no simple "hack in a new built-in".

ciao,
Torsten.

Wouldn't it be possible to have an elapsed time measurement for functions?
The majority of time testing I do is for functions, not geometry
production.

On Sun, Feb 9, 2025 at 1:19 PM Torsten Paul via Discuss <
discuss@lists.openscad.org> wrote:

On 2/9/2025 10:25 AM, Adrian Mariano via Discuss wrote:

I'm not quite as pessimistic as Torsten is, but timing functions would
have ... interesting ... semantics even today, and theoretically in the
future might get odder.

start = time();
mymodule();
end = time();
echo(end - start);

will report approximately zero, no matter what mymodule() does.  (All
assignments are executed before all module invocations.)

Theoretically, module invocations can run in parallel.  They can't
today, but I suspect that it wouldn't be that hard to do.

That would mean that

start = time();
mymodule();
echo(time() - start);

might also report approximately zero, when the echo runs in parallel
with mymodule().

Assignments could theoretically run in dependency order - in parallel
when there is no dependency.  In the first example above, the assignment
to "end" could run first.  We could also get rid of the "assignments
first" behavior, and run assignments and module invocations in
dependency order, in parallel.  Theoretically, we could parallelize
execution of the two sides of a binary operator.  For most OpenSCAD
programs, I suspect that parallelizing assignments or expressions
wouldn't be worth it, but for calculation-heavy programs like
BOSL2-based programs they might be.  (The trick would be finding the 5%
of the program that would benefit, without materially hurting the other
95%.)

Mostly, all of that parallelization would be completely invisible to the
generation of OpenSCAD models.  (It would not be invisible in console
output.)  The one current exception is that seeded random numbers -
random numbers where you supply a seed and expect the same sequence of
numbers - would fail completely.  You'd still get random numbers, but
they wouldn't be guaranteed to be the same sequence every time.

Is any of this likely to happen any time soon?  I wouldn't hold my
breath.  But I think one of the reasons that OpenSCAD has the ...
interesting ... semantics that it has is to enable this sort of
parallelism, if somebody ever gets interested in doing it.

Use the same syntax as let(). For example:

timetest() mymodule();

Or

result = timetest() myfunction();

They just call the module or function, and as a side effect, print to the console the number of microseconds elapsed.
Since all the children of the module have to complete before it returns, and all the parts of the function expression have to finish before it returns, you can get future-proof timings.

-Revar

A disadvantage of that approach would be that it doesn't let you
programmatically obtain the time data.  But I could see a version where

result = timetest() myfunc(),

runs the function and returns the function value but

result = timetest(return_time=true) myfunc(),

runs the function but returns the time instead of the function's return.

On Sun, Feb 9, 2025 at 2:41 PM Revar Desmera via Discuss <
discuss@lists.openscad.org> wrote:

On 09.02.25 19:25, Adrian Mariano via Discuss wrote:

There we go, good question as that refers to the first evaluation
step of the processing. I'm not sure what the original post
was asking, but I was assuming that was more about the 2nd part of
processing which is either GUI display or Mesh Render depending
on Preview/Render mode.

Functions are part of the AST, so I guess we would need to do
the annotation for both AST and geometry tree.

What I'm saying is it's not solved by a simple "measure()"
regardless of function evaluation or mesh render. That will
only help in some special cases.

Main point is that an OpenSCAD "program" is multiple steps
that are processing tree structures. It's not a single linear
code flow.

ciao,
Torsten.

May also want a label argument to print with the timing, so out of order issues are mitigated:

timetest(“The module”) mymodule();
x = timetest(“The function”) myfunc();

-Revar

I was thinking along the lines of:

start = time();
mymodule();
echo(time() - start);

If time is given in ms, then this makes sense.  This is how the
RenderStatistic.h source calculates the elapsetime.

If we had a time() function, and possibly a time_diff function, then I
can calculate the elapse time of different solutions.

EBo --

On Sun, Feb 9, 2025 at 2:56 PM Torsten Paul via Discuss <
discuss@lists.openscad.org> wrote:

You might have to resort to invoking it 10^6 times (or more) and using the
overall execution time to get an estimate.

On Sun, Feb 9, 2025 at 2:34 PM John David via Discuss <
discuss@lists.openscad.org> wrote:

That's assuming OpenSCAD doesn't memoize module calls, which I strongly
doubt it does.

On Sun, Feb 9, 2025 at 2:35 PM Father Horton fatherhorton@gmail.com wrote:

We’re told in the user guide not to assume OpenSCAD is sequential, so is
that approach even technically possible?

On Sun, 9 Feb 2025 at 12:34, John David via Discuss <
discuss@lists.openscad.org> wrote:

If you just intend to do some runtime-tests on previews and renders (F5
and F6), you can exploit the "Total rendering time" information provided
in the console window.  However don't forget to clear the cache if
modules are involved.

Am 09.02.2025 um 19:10 schrieb John David via Discuss:

I was asked to do some simple until tests for two alternatives of the
nurbs_length() function.  So far I have written some simple tests, and
copy/pasted the results run one at a time.  It would be nice to set up a
dozen edge cases and run them all at one go.  That is why I was asking if
there was any built-it time() or similar function.  I'm half tempted to try
to hack in a new built-in, but that is likely a heavy lift.

On Sun, Feb 9, 2025 at 5:21 PM Rudolf via Discuss <
discuss@lists.openscad.org> wrote:

While focusing on elapse time, I wrote a function time([prior]) that
returns the microseconds resolution time in seconds since the epoch.  If
you give it a prior time stamp, then it will return the difference in
seconds (microseconds resolution).  The diff to follow.  Please let me know
what you would like the API to really look like, and I will give it a go,
and send a proper pull request.

EBo --

diff --git a/src/core/builtin_functions.cc b/src/core/builtin_functions.cc
index 69d22bae5..2222123fe 100644
--- a/src/core/builtin_functions.cc
+++ b/src/core/builtin_functions.cc
@@ -47,6 +47,7 @@
#include <algorithm>
#include <random>
#include <vector>
+#include <chrono>

#include "utils/boost-utils.h"
// hash double
@@ -359,6 +360,26 @@ Value builtin_length(Arguments arguments, const
Location& loc)
return {double( arguments[0]->toStrUtf8Wrapper().get_utf8_strlen() )};
}

+Value builtin_time(Arguments arguments, const Location& loc)
+{

• // grab the high resolution clock in us
• auto now = std::chrono::duration_caststd::chrono::microseconds(

•        std::chrono::high_resolution_clock::now().time_since_epoch())
  

•        .count();
  

• // it appears that you can only return doubles, so convert the
• // microsecond clock to fractional seconds.
• double dnow = double(now)/1000000.0;
• if (arguments.size() == 1) {
• if (!check_arguments("time", arguments, loc, { Value::Type::NUMBER }))
  {

•   return Value::undefined.clone();
  

• }
• return {dnow - arguments[0]->toDouble()};
• }
• return {dnow};
  +}

Value builtin_log(Arguments arguments, const Location& loc)
{
double x, y;
@@ -1085,6 +1106,12 @@ void register_builtin_functions()
"ord(string) -> number",
});

• Builtins::init("time", new BuiltinFunction(&builtin_time),
• {
• "time() -> number",
• "time(number) -> number",
• });
• Builtins::init("concat", new BuiltinFunction(&builtin_concat),
  {
  "concat(number or string or vector, ...) -> vector",

On Sun, Feb 9, 2025 at 8:28 PM John David ebo.2112@gmail.com wrote: