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: