In response to your additional quick question 1:
The openSCAD window is not context aware for keyboard shortcuts in the console window. You can still copy, you have to select the text you want to copy and but then right(alternate)-click at which point a window will appear and you can select “copy”. Cmd-C doesn’t work.

40 holes F6 render took me

Total rendering time: 0:00:04.877

Removing 'render()' (which is equivalent to F6 render) F5 preview took

Compile and preview finished.

Total rendering time: 0:00:00.068

render() is an acquired taste, needed for some preview anomalies, best left alone until you gain
experience.

Some people like using it on small chunks so they cache.

Are you using $fn, $fa or $fs?

We are working on climate-change :-) don't want to use too much power...

History https://github.com/openscad/openscad/issues/391 .

OpenSCAD uses some complex libraries. OpenGL & CGAL being the main ones. Lookup CGAL.

On my 8GB (+SSD Swap) VM I have, 8000MB each, make yours bigger, 23000? It only gets used on
complex models.

the crashed code.

What error & what hang?

I can edit it before any rendering

Uncheck Design/Automatic-preview&render. And don't use render().

From: infocean via Discuss [mailto:discuss@lists.openscad.org]
Sent: Fri, 19 Mar 2021 15:30
To: discuss@lists.openscad.org
Cc: infocean
Subject: [OpenSCAD] Is there a "best practices" to speed up some operations?

Hi,

I have this little program:

// Some parameters
pmpgap = 0.2;
sposstart1 = 0;
intakel = 2;
intakew = 0.5;
indist = 4;
intakeholer = 0.2;
nintakeholes = 40;
pintake1 = sposstart1+1.5;
pintake2 = sposstart1+11.8;

// Module of the intake
module intake(){
/rotate([0,90,0])/
difference(){
rotate_extrude(convexity=10)
translate([indist,0,0])
rotate(45)
square([intakel,intakew],true);

for(i=[1:nintakeholes]) 
rotate([0,0,i*360/nintakeholes])     
translate([indist-0.5,0,-0.5]) 
    rotate([0,135,0]) 
    linear_extrude(height=intakew+0.5,center = true, convexity = 10, twist = 50) 
    circle(r=intakeholer); 
} 

}

// Draw the intakes
color("SlateBlue",0.4) render()
translate([pintake1,0,0])
intake();

When nintakeholes =3,5,20,40. the execution time is: 0:00:28.891, 0:01:57.659, 0:12:25.321,
0:34:03.133.  Looks to me time goes up faster than linear.  So, the question is how can the
rendering time be reduced.  I am a newbie, so I am just putting constructs one after another and do
not know what coding technics here would give the fastest, or minimum faster execution.
I am trying to code an intake cover, "covered" by holes all over.  I coded here just one circle of
holes, but I need to add 4-5 more, so air can go in freely.  That might take a whole day to render.

My machine has 12 cores.  Only one is working.  I also have 3 graphics card for computation.  None
of them is working.  If OpenSCAD could have been parallelized on the cores for geometry and the
math and vector computation outscored to the GPUs, the speed increase could be minimum 10 fold.

If it is a big work to rewrite, then maybe another language can be put into slave service - like
Julia which has built in parallelism and can handle the GPUs easily -, and pass to that language
all parallelizable  computation.  Julia although it is an interpreted language has a speed very
close to C++ if the coding done right.
Maybe the Google summer code camp can be a good occasion to go over the OpenSCAD code and see what
portions can be passed to the multicore CPU for parallelization and what portions can passed to the
GPUs for heavy lifting.

Additional quick questions:

1. When I highlight something in the Console window and select copy and then I try to paste it
   into another program's document - like right here -, Console gives me nothing.  What is the trick
   to be able to copy and paste just as I can do in any other programs?  I am on a Mac with OS X
   10.15.7.
2. I changed the cache sizes to 200MB from the default 100MB, but I see that even when I render the
   nintakeholes =20 case Console says: CGAL cache size in bytes: 199228304, so very close to 200MB.
   What is the recommended CGal and PolySet cache sizes to get the fastest rendering speed possible?
   I have 48GB in this machine and 23GB or so was not even touched.
3. It would be nice if after a coding error and OpenSCAd hang, the program would not want to F5
   the crashed code.  Actually it would be nice if at start when I open an scad file the rendering
   would not happen, so I can edit it before any rendering, let say to correct a bug in the code and
   render only if I hit <cmd>+<s>.  I am not seeing anything in Preferences to help me out in this
   regard.

Thanks ahead,
infocean

Sent from the OpenSCAD mailing http://forum.openscad.org/  list archive at Nabble.com.

--
This email has been checked for viruses by AVG.
https://www.avg.com

MichaelAtOz wrote

That would be Automatic-reload&preview...

OpenSCAD Admin - email* me if you need anything,  or if I've done something stupid...

• on the Forum, click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.

--
Sent from: http://forum.openscad.org/

Welcome to the 1980s.
Cheers, RobW

On 19 March 2021 3:30:01 pm AEDT, infocean via Discuss discuss@lists.openscad.org wrote:

On 19.03.2021 05:30, infocean via Discuss wrote:

In many cases you can run OpenSCAD scripts in AngelCAD and enjoy use of
multiple cores that way https://arnholm.github.io/angelcad-docs/
Yes you can get a 10 fold increase in speed.

However, for this particular example it does not work properly, since
you don't get an equivalent result. I have not researched why that is
so. But many other examples work fine.

Carsten Arnholm

On 19.03.21 05:30, infocean via Discuss wrote:

This has nothing to do with the language. The slow part
is the geometry engine which also had no easy way to run
threaded.

Using a different language would achieve exactly nothing.

The approach to increase speed is moving to a different
geometry calculation, which is done in
https://github.com/openscad/openscad/pull/3641
and may also open up the possibility to easier go multi
threaded, where earlier attempts struggle due to the
underlying library.

Google Summer of Code is now just about 180h of coding,
so there's essentially no way to have any of that as
topic, unless someone with lots of experience in that
area comes around and proposes this as project with a
very clear plan (which would be awesome!).

ciao,
Torsten.

On 3/18/2021 9:30 PM, infocean via Discuss wrote:

There must be something else going on here.

My PC is something like eight years old, and was not quite
bottom-of-the-line when I bought it.

With nintakeholes=40, a render takes about ten seconds.
With nintakeholes=3, a render takes under a second.

HI, All,

By taking out render() made the difference.

With render() :Total rendering time: 9:23:59.954

Without render() : Total rendering time: 0:00:00.449

Amazing! /Even as I added four more circles of holes/  My motivation to use render() was from some posts on the forum suggesting to be able to see the colors after F5.  But now looks like it is not needed for this purpose.  It would be great if F6 would also retain the color info.  More and more 3D printers are using multiple colors and I think I saw one which is using even millions of colors.

Yes, now I am able to “cut & paste”. Thanks for the info.

I looked over the History link.  Hmm… The team needs someone with parallelization experience to minimum distribute the computations among the available processors and cores.  Unfortunately I have no C++ experience, so I cannot volunteer.

Regarding the hanging and the “crash” I found out that they were not real crashes.  OpenSCAD just stopped communicating to the OS, so Activity Monitor reported it as “not responding”, but ultimately after some time the program finished the job.  Maybe in a future version OpenSCAD can communicate to the OS more frequently, so the watchdog like programs as Activity Monitor would not be confused regarding the true status of the program.

Yes I use some $ variables.  Here they are:
echo(version=version());
$fa=0.4;
$fs=0.4;
$fn=60;

Are they optimal for middle-complex jobs?

Thank you all,
Infocean

Are your values in inches or millimeters?  OpenSCAD doesn't care, but
most slicers default to millimeters.  Your part looks really small in
millimeters, and the holes are tiny.

On 3/19/2021 5:11 PM, (null) (null) via Discuss wrote:

The difference between your performance and the performance other people
are seeing on your model is the settings of $fa/$fs/$fn. Your settings
of 0.4/0.4/60 took a sub-second render with the default values to a
minute and a half for me, with three holes.  Just that $fn setting
accounts for most of it.  Assuming you're using inches, your "intake
holes" have a diameter of 0.4in; you're forcing them to each have 60
sides so each side is about 0.02in, below the resolution of a
conventional 3D printer.  If you're in mm, they'd be even tinier.

Mostly, don't mess with render() unless you're having problems with
preview artifacts.  But not messing with render() doesn't save you;
you'll need to do a full F6 render if you want to export to STL.

Yes.  https://github.com/openscad/openscad/issues/1608

On Windows, F6 render runs in a different thread from the UI, so the UI
remains live.  Unfortunately, F5 preview, even if it's doing a render(),
runs in the same thread as the UI and so the UI freezes while it runs.

Note that these weren't in the sample you posted.  They can make a huge
difference in performance.

Mostly, I suggest that you don't mess with $fn unless you need to force
a particular number of sides because you want a hexagon or whatever.

$fa=0.4 is really small.  Looking only at the effect of $fa, if you set
it to 2 it is hard to see the polgon-ness of the result unless you look
really closely.  Larger numbers are more visible but still probably fine
for 3D printing.

$fs=0.4 is really small.  It's saying that you want the polygon sides to
be 0.4 units or less - typically, 0.4mm or less.  Unless your circles
are down in the couple-of-millimeter range, that's more precise than you
need.

These two parameters work together to keep your circles from having a
uselessly large number of sides.  One way to look at it is that $fa
controls the behavior of large circles and $fs controls the behavior of
small circles.

You can probably pick values for $fa and $fs that will make both small
circles and big circles look good, without making either have an
unreasonable number of sides.  Try $fa=5 and $fs=1 and see how it works
for you.  Actually print some models; the sides are more visible on the
screen than they are in plastic.