Are you using a somewhat recent dev snapshot?  The CSG Tree generation and
key storing got reworked significantly in the past year.

With the example you gave I get 7s preview and "Geometries in cache: 1". I
see that yours is showing 395 geometries so either your posted example
simplified away the cause of the issue, or something different between with
the build you are running.

On Mon, Jan 28, 2019 at 2:59 AM nop head nop.head@gmail.com wrote:

I am using a snapshot from yesterday.

I only get one geometry if that is the only file loaded. I had more MDI
windows open when I posted yesterday.

You might have a machine that is three times faster than this laptop but
even so 7 seconds seems slow to me. It has to read about 1 million faces
from a list and convert them into Polysets which are just vectors of
vectors of vertices. Perhaps I have just lost touch with how inefficient
modern software is.

OpenSCAD 2019.01.27.ci1306
https://www.openscad.org/

Copyright (C) 2009-2019 The OpenSCAD Developers

This program is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the Free
Software Foundation; either version 2 of the License, or (at your option)
any later version.

Loaded design 'C:/Users/ChrisP/Documents/springs.csg'.

Compiling design (CSG Tree generation)...

Compiling design (CSG Products generation)...

Geometries in cache: 1

Geometry cache size in bytes: 657560

CGAL Polyhedrons in cache: 0

CGAL cache size in bytes: 0

Compiling design (CSG Products normalization)...

Normalized CSG tree has 100 elements

Compile and preview finished.

Total rendering time: 0 hours, 0 minutes, 21 seconds

On Mon, 28 Jan 2019 at 10:31, Hans L thehans@gmail.com wrote:

thehans wrote

I tried some older snaps with 100 copies of a sweep object, each containing
19002 facets and no buffering of the points and faces: one from 2016
(1'36"), one from 2017 (1'16"), one from 2018 (1'00") and a recent 2019
(1':00"). So there was some progress.
With buffering of points and faces the 2019 version needed 0'42".

As compiling an own fork of OpenSCAD is not recommended on Windows (too much
effort to set it up), I don't know the code well enough to be able to follow
what is happening in an F5 context. But I am curious.

Can anybody provide a sketch of how the execution goes on after
createGeometry()?

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

I think the majority of the time is taken in createGeometry, not after it
it.

100 spheres with $fn set to 150, which gives  11250 vertices each, only
takes 1 second, presumably because it is cached, or it is 20 times quicker
to calculate vertices with trig than it is to read them from a list.

On Mon, 28 Jan 2019 at 14:40, Parkinbot rudolf@digitaldocument.de wrote:

Well for reference my cpu is: Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz, I
wouldn't expect it to be 3x faster than a 2.5GHz core i7..

I am testing on Linux, not Windows, so maybe that is the main difference. I
wonder if Windows snapshots are not getting the same -O2 compiler
optimizations?

But anyways, the main thing about caching is that it doesn't simply cache a
call to a module.  OpenSCAD first converts the entire script into csg
format which is just a static representation of primitives, multmatrix
transformations and boolean operations, so it has to evaluate all lists
comprehensions, control structures etc, creating scope for each node etc;
essentially building up the entire output that you see in .csg export, in
memory (about 31.6MB of text for nopheads example, although in memory it
should be a bit less due to whitespace/indentation stripping).  Then it
caches Polysets for matching subtrees (substrings basically of any node and
its children) from this .csg representation.

Compare the 31.6MB to the size of the .csg output of your sphere example,
that's gonna be like a couple kb of text processing.

On Mon, Jan 28, 2019 at 11:01 AM nop head nop.head@gmail.com wrote:

It is only 31.6MB in the csg because the lists are text and are repeated
over and over again. But at runtime there should only be one copy of the
lists in binary. Does it really generate a textual csg representation in
memory or is that just when you dump it? And does it actually make 100
copies of the lists by value? That might explain why it is so slow.

On Mon, 28 Jan 2019 at 18:08, Hans L thehans@gmail.com wrote:

Yes it really does.  The csg text representation of a node is its cache
key.  And the csg format doesn't really do individual variable (list)
caching.

On Mon, Jan 28, 2019 at 12:41 PM nop head nop.head@gmail.com wrote:

I did some profiling and found that its spending much of its time in
PolysetUtils::tessellate_faces, because its re-tessellating each geometry
after pulling from geometry cache.  Ideally it should tesselate only once
before putting into the cache.  Pull request incoming. :)

On Mon, Jan 28, 2019 at 12:47 PM Hans L thehans@gmail.com wrote:

I am totally confused because in the source code it is just passed as a
variable that happens to be a list. Where does it get converted to back a
string again and parsed? Or are OpenSCAD lists just vectors of strings?

And as for re-tessellating. How long does it take to tessellate something
that is already mostly triangles? Should I manually tessellate the end caps
with a triangle fan? The other 9000+ facets are already triangles.

On Mon, 28 Jan 2019 at 21:30, Parkinbot rudolf@digitaldocument.de wrote: