Below is an example of when I use a for loop, the preview is SUPER SLOW
compared to when I do the same thing manually.

Set /useFor /to *true *and rotating around the object is disgustingly slow
compared to if /useFor=false/.  This is just an example. It gets worse
when I add more spheres to this in the union.  Funny thing is, the letters
can be totally engulfed in the spheres so that they don't show up, and it is
still slow.  Something going wrong with the caching?  What's going on?

Using OpenSCAD version 2015.01.23 (git 5a0c4b0).

A

--
View this message in context: http://forum.openscad.org/Why-is-for-so-slow-tp11511.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

Oops, set d=5 at the beginning.

A

--
View this message in context: http://forum.openscad.org/Why-is-for-so-slow-tp11511p11512.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

Oh and get rid of the heart() call in letters().

A

--
View this message in context: http://forum.openscad.org/Why-is-for-so-slow-tp11511p11513.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

a. If this was just the first time, it needs to build the font cache. As it
seems you have tried a few things I assume that is not the cause.

b. for me, on the same version, it is fine. (W7/64bit)

c. "the letters can be totally engulfed in the spheres so that they don't
show up, and it is still slow." even tho they are engulfed, they still need
calculating to know they are engulfed. But as it is not slow for me...

d. What H/W and S/W platform? (check your graphics drivers are up to date).

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. This work is published globally via the internet. :) Inclusion of works of previous authors is not included in the above.

The TPP is no simple “trade agreement.”  Fight it! http://www.ourfairdeal.org/

View this message in context: http://forum.openscad.org/Why-is-for-so-slow-tp11511p11515.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

I can't reproduce the problem here (Windows x64 2014.12.04). Both versions
are fast.

--
View this message in context: http://forum.openscad.org/Why-is-for-so-slow-tp11511p11518.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

My SW (OS) is Win7.  My hardware is an older (3-4 yo) Dell Inspiron N411Z
laptop with 8GB RAM, 1TB 5400RPM HD, i4-2450M CPU @ 2.5GHz with built in
Intel HD Graphics Family video.

I'll see if I can get any driver updates, but the fact that it is slower on
my machine indicates a significant run time path divergence.

Turns out the slowdown is caused by the interaction of the /for loop/ with
the /intersection()/ of the /heart()/ in /letters()/.  Without the
/intersection()/, the problem isn't seen.  See the following (this is a be
complete sample):

Now you should see some slowdown.  I removed a sphere in the heart() module
because the programme almost died (even comes close with 3 spheres).

A

--
View this message in context: http://forum.openscad.org/Why-is-for-so-slow-tp11511p11519.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

Yes, I see the slowdown now. But in all honesty, the way you're doing
debugging is wrong. You're not creating the shortest code to show the
problem, and testing the role of the for loop incorrectly.

Thank about it: to test if the for loop is the problem, you should expand it
manually and see if you get a difference. for (i=[0:3]) { module(i); }
should be expanded to union() { module(0); module(1); module(2); module(3);
} to test if the for loop is the problem.

You put completely different code inside the for loop and the else
(useFor=0) branch. Of course the timing is going to be different. It's
executing different code. It has nothing to do with the for loop.

This code should test the for loop, and show that using a loop vs. writing
the code manually has no impact on speed (both are slow):
d=5;

module heart()
{
scale([1,.5,1])
{
translate([-d3/4,0,0])
sphere(r=d, $fn=30);
translate([d3/4,0,0])
sphere(r=d, $fn=30);
translate([0,0,d3/4])
sphere(r=d, $fn=30);
translate([0,0,-d*3/4])
sphere(r=d, $fn=30);
}
}

module torus(majorR, minorR)
{
rotate_extrude(convexity = 10, $fn=50)
translate([majorR,0,0])
circle(r=minorR, $fn=30);
}

module part(useFor)
{
scale(1)
//rotate([0,180,0])
{
difference()
{
d=0.4;
o=0.2;
heart();

  if (useFor)
  {
    for(i=[0:3])
    {
      letters(i, o=o, d=d);
    }
    translate([0,0,21])
    rotate([90,0,0])
    torus(19, .8);
  }
  else
  {
    union()
    {

      letters(0, o=o, d=d);
      letters(1, o=o, d=d);
      letters(2, o=o, d=d);
      letters(3, o=o, d=d);

    }
    translate([0,0,21])
    rotate([90,0,0])
    torus(19, .8);
  }
}

• for(i=[0:3])
  letters(i, 0);
  }
  }

function RTTs(i) = [
[[ 87,0,0],  [-9/2-.4, -2, 1.5], "AA"],
[[103,0,0],  [-2,      -7, 2  ], "B" ],
[[ 87,0,180], [-9/2-.4, -2, 1.5], "CC"],
[[103,0,180], [-2,      -7, 2  ], "D" ]
][i];

module letters(i,o,d=0)
{
scale(1)
intersection()
{
heart();

rotate(RTTs(i)[0])
translate(RTTs(i)[1]+[0,0,-d])
linear_extrude(height=1+d)
offset(delta=o)
text(RTTs(i)[2], size=5);

}
}

part(useFor=0);

Have a nice day,
Bananapeel :)

--
View this message in context: http://forum.openscad.org/Why-is-for-so-slow-tp11511p11520.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

Right, so its the intersection() that's the problem.  The "loop" had more
intersection() operations then the non-loop, causing a slow down.

Thanks,

A

--
View this message in context: http://forum.openscad.org/Why-is-for-so-slow-tp11511p11523.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

Still, after generating the code, I would have expected that the data
vertices and faces would have been cached and not have to  redo them every
time the POV changes.

A

--
View this message in context: http://forum.openscad.org/Why-is-for-so-slow-tp11511p11524.html
Sent from the OpenSCAD mailing list archive at Nabble.com.