Aha!  Minimal code to reproduce:
use.scad:

function foo(x) = x;
x=echo("DANGER DANGER! DANGER, Will Robinson!");

main.scad:

use <use.scad>
y = foo(2);

Output:

Used file cache size: 2 files
Compiling design (CSG Tree generation)...
ECHO: "DANGER DANGER! DANGER, Will Robinson!"
Compiling design (CSG Products generation)...
Geometries in cache: 1
Geometry cache size in bytes: 728
CGAL Polyhedrons in cache: 0
CGAL cache size in bytes: 0
Compiling design (CSG Products normalization)...
Normalized CSG tree has 0 elements
Compile and preview finished.
Total rendering time: 0 hours, 0 minutes, 0 seconds

• Revar

Call foo() a few more times in main.scad, and you'll see the text echoed for every call.

• Revar

I tried including my math functions into my sweep code instead of using
them. It made some of my tests very slightly faster and some slightly
slower. The downside of include is it has to re-parse the code each time
instead of using the module cache.

I don't really have any high frequency calls across file boundaries, which
is why I haven't noticed this effect. I haven't got anything approaching
the complexity of calculating a hull in user space. This got me thinking
that perhaps OpenSCAD should provide all the CSG ops as functions that take
parameters like polyhedron and return the same. That would allow geometry
to be computed without breaking anything. Of course if you called a union
or minkowski function it would make the compilation crazily slow.

Yes variables seem to re evaluated when you call a function in a used
module but I am sure functions and modules are not recompiled because that
is done at parse time and the AST is cached in the module cache. So there
isn't anything to do for a function unless it is called by a variable
initialisation.

On Sun, 14 Apr 2019 at 03:15, Revar Desmera revarbat@gmail.com wrote:

I  don't think that's necessary, and even if we continue doing it, it should be possible to perform some sort of Common Expression Elimination.
This probably went largely unnoticed since until the recently introduced echo() function, we didn't really have functions with side effects.

-Marius

To test my own library I time each test and store the results in a JSON
file. At the end of the test I show which got faster or slower by
significant amounts by showing the delta and colouring red and green and I
rank them by time. Here is the last run. As soon as I added this it
prompted me to start investigating how to make it go faster. It started at
972 seconds and now 172.3. It does vary a bit randomly as my PC is doing
other things. Perhaps the OpenSCAD test suite should do the same to
highlight how performance is changing.

[image: image.png]

On Sun, 14 Apr 2019 at 17:40, Torsten Paul Torsten.Paul@gmx.de wrote:

On 14.04.19 19:29, nop head wrote:

Yes, that's pretty much what I'm thinking too. But as we run tests
on various machines it's not that simple as we don't want to have
lots of random errors flagged just because we got a slower worker
VM assigned for a build.

That's why I hope we might be able handle that using a couple of
specific test cases which have a reasonable long run time and
compare those against some base line tests. That way it would
only trigger notifications in case the relative time is changing
a lot and not absolute runtime.

ciao,
Torsten.

Yes I measure the time to preview a large PNG using the command line. It is
about 1.5 seconds slower than F5 preview but I am exporting a 4096 x 4096
image. I do that because viewall is quite conservative and leaves a large
border. I then use image magick to trim the border and downsize it to 1280
width to give some anti-aliasing. The results look like this.

[image: d_connectors.png]

On Sun, 14 Apr 2019 at 22:40, MichaelAtOz oz.at.michael@gmail.com wrote: