Module reuse?
If I have a main.scad file that uses a.scad and b.scad and they both use
c.scad does OpenSCAD process c.scad twice and keep two separate copies in
memory or is one copy of c.scad re-used?
Is it any different if main.scad includes a.scad and b.scad?
I ask because every sub assembly file in Mendel90 includes a library of
parts and utilities. They also include other sub assemblies which all
include all those parts. Would using the parts instead of including them be
more efficient?
On Oct 19, 2016, at 13:29, nop head nop.head@gmail.com wrote:
If I have a main.scad file that uses a.scad and b.scad and they both use c.scad does OpenSCAD process c.scad twice and keep two separate copies in memory or is one copy of c.scad re-used?
We cache used files but not included files:
In this case we will only parse c.scad once, and cache those results until the timestamp of c.scad or any dependencies of c.scad changes.
Is it any different if main.scad includes a.scad and b.scad?
In that case, we don’t cache a.scad and b.scad, but c.scad will still be cached as it’s used, not included.
I ask because every sub assembly file in Mendel90 includes a library of parts and utilities. They also include other sub assemblies which all include all those parts. Would using the parts instead of including them be more efficient?
It will be more efficient as you’d save some time in the parsing step. However, if most of your time is spent doing other stuff than parsing, it unlikely to have a large impact.
-Marius
Parsing does take significant time because at the moment all the vitamins
are included, so they all get parsed for every assembly. I am designing a
new machine so I will include only the constants and use all the modules
and functions. This means splitting each vitamin file into two parts. For
example screws,scad is a list of screw definitions, which are just named
lists. A second file screw.scad will contain all the functions and modules
related to screws and will be included in screws.scad. Hopefully that will
be much faster and possibly fix the slowdown when automatic reload is
turned on.
On 20 October 2016 at 17:19, Marius Kintel marius@kintel.net wrote:
On Oct 19, 2016, at 13:29, nop head nop.head@gmail.com wrote:
If I have a main.scad file that uses a.scad and b.scad and they both use
c.scad does OpenSCAD process c.scad twice and keep two separate copies in
memory or is one copy of c.scad re-used?
We cache used files but not included files:
In this case we will only parse c.scad once, and cache those results until
the timestamp of c.scad or any dependencies of c.scad changes.
Is it any different if main.scad includes a.scad and b.scad?
In that case, we don’t cache a.scad and b.scad, but c.scad will still be
cached as it’s used, not included.
I ask because every sub assembly file in Mendel90 includes a library of
parts and utilities. They also include other sub assemblies which all
include all those parts. Would using the parts instead of including them be
more efficient?
It will be more efficient as you’d save some time in the parsing step.
However, if most of your time is spent doing other stuff than parsing, it
unlikely to have a large impact.
-Marius
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Related to this: I’m considering changing how files are included by parsing all included files separately, and merging the symbols into the namespace of the including file as a separate step. This will enable caching also of included files.
..at the expense of breaking backwards compatibility by requiring included files to contain fully parsable statements.
-Marius
On Oct 20, 2016, at 12:51, nop head nop.head@gmail.com wrote:
Parsing does take significant time because at the moment all the vitamins are included, so they all get parsed for every assembly. I am designing a new machine so I will include only the constants and use all the modules and functions. This means splitting each vitamin file into two parts. For example screws,scad is a list of screw definitions, which are just named lists. A second file screw.scad will contain all the functions and modules related to screws and will be included in screws.scad. Hopefully that will be much faster and possibly fix the slowdown when automatic reload is turned on.
Included files see the symbols of the file they are included in, so if they
are included into more than one they can produce module and functions that
behave differently. Won't caching them break that?
On 20 October 2016 at 19:42, Marius Kintel marius@kintel.net wrote:
Related to this: I’m considering changing how files are included by
parsing all included files separately, and merging the symbols into the
namespace of the including file as a separate step. This will enable
caching also of included files.
..at the expense of breaking backwards compatibility by requiring included
files to contain fully parsable statements.
-Marius
On Oct 20, 2016, at 12:51, nop head nop.head@gmail.com wrote:
Parsing does take significant time because at the moment all the
vitamins are included, so they all get parsed for every assembly. I am
designing a new machine so I will include only the constants and use all
the modules and functions. This means splitting each vitamin file into two
parts. For example screws,scad is a list of screw definitions, which are
just named lists. A second file screw.scad will contain all the functions
and modules related to screws and will be included in screws.scad.
Hopefully that will be much faster and possibly fix the slowdown when
automatic reload is turned on.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On Oct 20, 2016, at 15:06, nop head nop.head@gmail.com wrote:
Included files see the symbols of the file they are included in, so if they are included into more than one they can produce module and functions that behave differently. Won't caching them break that?
No - the parsing itself isn’t context sensitive.
Defining behavior isn’t the job of the parser, that’s done in a separate step; when evaluating the AST into a CSG tree. This step is a bit harder to cache due to the existence of dynamically bound symbols, like $fn.
-Marius