A
adrianv
Sat, Apr 13, 2019 11:40 AM
I was trying to optimize some code and the things that were helping weren't
making a lot of sense. I finally realized that if I used "include" to use
my library instead of "use" my code ran about 3 times faster. (I suspect
that "optimization" was achieved by anything that decreased the number of
function calls to the library.)
Now one reason this might happen, as recently discussed, is top level
variables in my library file. The included file contains only function
definitions, no variables and no modules. So what is going on here?
--
Sent from: http://forum.openscad.org/
I was trying to optimize some code and the things that were helping weren't
making a lot of sense. I finally realized that if I used "include" to use
my library instead of "use" my code ran about 3 times faster. (I suspect
that "optimization" was achieved by anything that decreased the number of
function calls to the library.)
Now one reason this might happen, as recently discussed, is top level
variables in my library file. The included file contains only function
definitions, no variables and no modules. So what is going on here?
--
Sent from: http://forum.openscad.org/
NH
nop head
Sat, Apr 13, 2019 2:01 PM
I suppose local functions are used in preference the used ones, so perhaps
it looks up names in the local scope and then each of the used files in
turn. Do you have more than one used file, if so does the order make a
difference?
I remember coding in interpreted Basic and it ran faster if you put
frequently call subroutines at the beginning simply because it did a linear
search from the start.
On Sat, 13 Apr 2019 at 12:41, adrianv avm4@cornell.edu wrote:
I was trying to optimize some code and the things that were helping weren't
making a lot of sense. I finally realized that if I used "include" to use
my library instead of "use" my code ran about 3 times faster. (I suspect
that "optimization" was achieved by anything that decreased the number of
function calls to the library.)
Now one reason this might happen, as recently discussed, is top level
variables in my library file. The included file contains only function
definitions, no variables and no modules. So what is going on here?
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
I suppose local functions are used in preference the used ones, so perhaps
it looks up names in the local scope and then each of the used files in
turn. Do you have more than one used file, if so does the order make a
difference?
I remember coding in interpreted Basic and it ran faster if you put
frequently call subroutines at the beginning simply because it did a linear
search from the start.
On Sat, 13 Apr 2019 at 12:41, adrianv <avm4@cornell.edu> wrote:
> I was trying to optimize some code and the things that were helping weren't
> making a lot of sense. I finally realized that if I used "include" to use
> my library instead of "use" my code ran about 3 times faster. (I suspect
> that "optimization" was achieved by anything that decreased the number of
> function calls to the library.)
>
> Now one reason this might happen, as recently discussed, is top level
> variables in my library file. The included file contains only function
> definitions, no variables and no modules. So what is going on here?
>
>
>
>
> --
> Sent from: http://forum.openscad.org/
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
A
adrianv
Sat, Apr 13, 2019 2:46 PM
There is a difference depending on the order of the "use" statements. If I
put the library in question first run and use "use" instead of "include" run
time rises by 100% in one of my tests. If I put the "use" statement last
run time rises by 125%.
--
Sent from: http://forum.openscad.org/
There is a difference depending on the order of the "use" statements. If I
put the library in question first run and use "use" instead of "include" run
time rises by 100% in one of my tests. If I put the "use" statement last
run time rises by 125%.
--
Sent from: http://forum.openscad.org/
NH
nop head
Sat, Apr 13, 2019 3:25 PM
I think you are treading new ground because most OpenSCAD code spends all
its time creating geometry. The time to run the script to is usually
negligible. I typically use about 70 files and it starts CSG product
generation within a second or two. I do have one project that takes about
10 seconds, so I will look at the order I use things to see if I can reduce
that.
On Sat, 13 Apr 2019 at 15:47, adrianv avm4@cornell.edu wrote:
I think you are treading new ground because most OpenSCAD code spends all
its time creating geometry. The time to run the script to is usually
negligible. I typically use about 70 files and it starts CSG product
generation within a second or two. I do have one project that takes about
10 seconds, so I will look at the order I use things to see if I can reduce
that.
On Sat, 13 Apr 2019 at 15:47, adrianv <avm4@cornell.edu> wrote:
> There is a difference depending on the order of the "use" statements. If I
> put the library in question first run and use "use" instead of "include"
> run
> time rises by 100% in one of my tests. If I put the "use" statement last
> run time rises by 125%.
>
>
>
>
>
> --
> Sent from: http://forum.openscad.org/
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
A
adrianv
Sat, Apr 13, 2019 3:56 PM
At least at the moment I'm not talking about huge amounts of time, tens of
seconds. But the time to preview the objects is clearly dominated by the
computations, not by the graphics.
--
Sent from: http://forum.openscad.org/
At least at the moment I'm not talking about huge amounts of time, tens of
seconds. But the time to preview the objects is clearly dominated by the
computations, not by the graphics.
--
Sent from: http://forum.openscad.org/
NH
nop head
Sat, Apr 13, 2019 4:11 PM
What sort of computations are you doing? The most intensive thing I do is
sweeps along Bezier paths but it only take a few seconds to do several of
them.
On Sat, 13 Apr 2019 at 16:57, adrianv avm4@cornell.edu wrote:
What sort of computations are you doing? The most intensive thing I do is
sweeps along Bezier paths but it only take a few seconds to do several of
them.
On Sat, 13 Apr 2019 at 16:57, adrianv <avm4@cornell.edu> wrote:
> At least at the moment I'm not talking about huge amounts of time, tens of
> seconds. But the time to preview the objects is clearly dominated by the
> computations, not by the graphics.
>
>
>
> --
> Sent from: http://forum.openscad.org/
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
A
adrianv
Sat, Apr 13, 2019 4:21 PM
I wrote a library for producing semi-regular polyhedra. The computations are
first using Linde's hull() function to find the convex hull faces of the
polyhedron's vertices---but it produces a list of triangles. I need to have
the actual faces, which can be octagons or decagons, so I assemble the
triangles into the full faces of the polyhedron. This last step was taking
3 times as long as doing the convex hull, which seemed really strange, which
was why I started trying to optimize.
I have a test case where I display ~100 polyhedra which is what I've been
using to assess run time.
--
Sent from: http://forum.openscad.org/
I wrote a library for producing semi-regular polyhedra. The computations are
first using Linde's hull() function to find the convex hull faces of the
polyhedron's vertices---but it produces a list of triangles. I need to have
the actual faces, which can be octagons or decagons, so I assemble the
triangles into the full faces of the polyhedron. This last step was taking
3 times as long as doing the convex hull, which seemed really strange, which
was why I started trying to optimize.
I have a test case where I display ~100 polyhedra which is what I've been
using to assess run time.
--
Sent from: http://forum.openscad.org/
RD
Revar Desmera
Sun, Apr 14, 2019 12:37 AM
I suspect part of the delay isn't just search order, but that it's actually re-defining/recompiling the functions on each use. The fact that echo()s at top-level are executed any time a function in a used library is called, makes me suspect the function declarations are also being re-executed.
This could be verified by having a used file, with the function you want to call at the beginning, named something like aaaa(). Fill the file with a lot of other function declarations after it. If the number of function declarations affects runtime, it's probably spending time re-declaring functions.
At this point, it looks like the use of use is severely dis-indicated.
I suspect part of the delay isn't just search order, but that it's actually re-defining/recompiling the functions on each use. The fact that echo()s at top-level are executed any time a function in a used library is called, makes me suspect the function declarations are also being re-executed.
This could be verified by having a used file, with the function you want to call at the beginning, named something like `aaaa()`. Fill the file with a lot of other function declarations after it. If the number of function declarations affects runtime, it's probably spending time re-declaring functions.
At this point, it looks like the use of `use` is severely dis-indicated.
- Revar
> On Apr 13, 2019, at 7:46 AM, adrianv <avm4@cornell.edu> wrote:
>
> There is a difference depending on the order of the "use" statements. If I
> put the library in question first run and use "use" instead of "include" run
> time rises by 100% in one of my tests. If I put the "use" statement last
> run time rises by 125%.
>
>
>
>
>
> --
> Sent from: http://forum.openscad.org/
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
JB
Jordan Brown
Sun, Apr 14, 2019 12:59 AM
On 4/13/2019 5:37 PM, Revar Desmera wrote:
I suspect part of the delay isn't just search order, but that it's actually re-defining/recompiling the functions on each use. The fact that echo()s at top-level are executed any time a function in a used library is called, makes me suspect the function declarations are also being re-executed.
With 2019.01-RC2 I don't see the behavior that you describe.
I have a main file
use <use.scad>
foo();
translate([10,10]) foo();
echo(f(0));
and use.scad is:
echo("top");
module foo() {
cube();
}
function f(n) = n+1;
echo("bottom");
and the only echo output is the expected "ECHO: 1".
On 4/13/2019 5:37 PM, Revar Desmera wrote:
> I suspect part of the delay isn't just search order, but that it's actually re-defining/recompiling the functions on each use. The fact that echo()s at top-level are executed any time a function in a used library is called, makes me suspect the function declarations are also being re-executed.
With 2019.01-RC2 I don't see the behavior that you describe.
I have a main file
use <use.scad>
foo();
translate([10,10]) foo();
echo(f(0));
and use.scad is:
echo("top");
module foo() {
cube();
}
function f(n) = n+1;
echo("bottom");
and the only echo output is the expected "ECHO: 1".
RD
Revar Desmera
Sun, Apr 14, 2019 2:03 AM
Well THIS is interesting. I know I reproduced nop head's results with the version of OpenSCAD I'm running (2019-03-03) just a week or so ago.
But this code below does NOT reproduce it.
I suspect part of the delay isn't just search order, but that it's actually re-defining/recompiling the functions on each use. The fact that echo()s at top-level are executed any time a function in a used library is called, makes me suspect the function declarations are also being re-executed.
With 2019.01-RC2 I don't see the behavior that you describe.
I have a main file
use <use.scad>
foo();
translate([10,10]) foo();
echo(f(0));
and use.scad is:
echo("top");
module foo() {
cube();
}
function f(n) = n+1;
echo("bottom");
and the only echo output is the expected "ECHO: 1".
Well THIS is interesting. I know I reproduced nop head's results with the version of OpenSCAD I'm running (2019-03-03) just a week or so ago.
But this code below does NOT reproduce it.
- Revar
> On Apr 13, 2019, at 5:59 PM, Jordan Brown <openscad@jordan.maileater.net> wrote:
>
> On 4/13/2019 5:37 PM, Revar Desmera wrote:
>> I suspect part of the delay isn't just search order, but that it's actually re-defining/recompiling the functions on each use. The fact that echo()s at top-level are executed any time a function in a used library is called, makes me suspect the function declarations are also being re-executed.
>
> With 2019.01-RC2 I don't see the behavior that you describe.
>
> I have a main file
> use <use.scad>
>
> foo();
> translate([10,10]) foo();
> echo(f(0));
> and use.scad is:
> echo("top");
>
> module foo() {
> cube();
> }
>
> function f(n) = n+1;
>
> echo("bottom");
> and the only echo output is the expected "ECHO: 1".
