On Feb 9, 2015, at 12:25 PM, nop head nop.head@gmail.com wrote:

Could you point to an example, so I can make some tests?

We generally try to avoid performance regressions. In particular for previews.
We did end up with some lower performance in a few places due to the need to triangulate almost planar faces. That would introduce a slight function call overhead while rendering.

-Marius

I noticed it rendering Mendel90. You could download it from git and open
scad/main.scad and press F5.

It seems to take about 5 seconds to render a frame when you drag with the
mouse. 2013.06 takes about 1 second. That still seems poor when most
objects have render() statements in them, so should just be a mesh to draw.

On 9 February 2015 at 22:12, Marius Kintel marius@kintel.net wrote:

Even a relatively simple design with only four render()ed parts chugs at
about one frame per second whereas it pans and rotates in real time with
the old version.

On 11 February 2015 at 11:35, nop head nop.head@gmail.com wrote:

An odd thing I noticed is OpenScad seems to use about 80% of one core even
when it is minimised and doing nothing. This is true of both the old and
the new version.

Also I am not sure the problem is simply slow drawing. If I drag the mouse
continuously is seems to draw a short burst of frames rapidly and then
pause for nearly a second and then repeat. It seems like it spends most of
the time doing something else. The old version will draw contiguously if I
move the mouse continuously and that revs up the graphics card fan. The new
one doesn't spend enough time drawing to do that.

On 11 February 2015 at 14:13, nop head nop.head@gmail.com wrote:

On Feb 11, 2015, at 09:13 AM, nop head nop.head@gmail.com wrote:

That doesn’t looks like a Mendel90 part. Could you share that design?

-Marius

On 02/11/2015 06:54 AM, nop head wrote:

hi,

if the design for the image that is shown is not proprietary, could you
please post the .scad?  i'd like to see what it is that you are doing...

thanks!
yvette

Not easily because it has lots of dependencies but the render in short
bursts issue seems to be any part of Mendel90. For example bar-clamps.scad
does it.

On 11 February 2015 at 16:25, Marius Kintel marius@kintel.net wrote:

Turning off automatic reload seems to fix the pausing issue.

On 11 February 2015 at 16:31, nop head nop.head@gmail.com wrote:

I think the pausing might be proportional to the number of dependent files
when auto reload is on.

On 11 February 2015 at 16:45, nop head nop.head@gmail.com wrote:

On Feb 11, 2015, at 06:35 AM, nop head nop.head@gmail.com wrote:

That is curious. I get ca. 5 fps on the full Mendel90 design here.
Which hardware are you using?

Also, you’re comparing to 2013.06 (which is ancient). How does 2014.03 relate to all this?
I don’t see a noticeable difference between the versions.

-Marius

On Feb 11, 2015, at 11:48 AM, nop head nop.head@gmail.com wrote:

That would make sense. The auto-reload is checking for any changes and this feature was improved to pick up changes in dependencies too.
The dependency walking apparently takes a bit of time on some systems. We should look into using OS-specific file change notification services as they’re likely a lot faster, at least on systems which offer such services.

Anyway, I’ll have a second look at this in case there’s a bug which causes excessive checking.

Just to clarify: Does turning off Auto-reload resolve all the performance regressions you reported?

-Marius

Yes, with auto reload turned off the latest version is actually much more
responsive than the old one with the full model loaded.

Older versions are fine with it turned on. The latest I have is
2014.02.25.  Do you want me to try 2014.03?

I have never updated from 2013.06 because it does everything I need. My
only desire was concat, but that didn't make it until this last one I
believe.

It seems like it is nothing to do with rendering but something to do with
looking for file changes. It doesn't rattle the disk so the file stats must
all be cached so I don't see why it would be slow.

On 11 February 2015 at 16:59, Marius Kintel marius@kintel.net wrote:

On Feb 11, 2015, at 12:16 PM, nop head nop.head@gmail.com wrote:

We did fix a number of automatic reload issues in 2014.03 - I think you initiated the bug reports which led to those fixes.
This was related to burst-writing of files, as well as correctly picking up dependencies.

I’m pretty sure that the performance issues was introduced in that release.
If you could verify that 2014.03 and 2015.02-RC2 behave in the same way for you, that would indeed be very helpful.

-Marius

On Feb 11, 2015, at 12:16 PM, nop head nop.head@gmail.com wrote:

PS! In 2015.02 we have some features which may work for you, in addition to concat (and list comprehensions):

o View All in GUI
o Ability to write to camera parameters in the .scad file
o Much faster hull() and minkowski() for common cases
o Much faster 2D pipeline

-Marius

OK I will try 2014.03.

2013.06 does slow down appreciably when the full model is loaded and auto
reload is on but nowhere near as much as 2015, so I hadn't noticed it.

On 11 February 2015 at 17:28, Marius Kintel marius@kintel.net wrote:

2015.02 reduces the first render time from 20 minutes 27 to 17 minutes 20
second, which is worth having.

The view all seems to shrink the Mendel90 excessively, perhaps because it
is tall and thin.

I noticed the load directory is no longer relative to the file that is
currently loaded. It seemed to get changed by opening a file in another
instance. This is very confusing for me because I have nearly identical
development and release directory structures so I ended up loading the
wrong version and when it takes 17 minutes that is not good. Also it is
hard to spot as there isn't much difference.

On 11 February 2015 at 17:36, nop head nop.head@gmail.com wrote:

On Wed, 11 Feb 2015 17:16:13 +0000
nop head nop.head@gmail.com wrote:

Would this be on a Windows system?

I've been bitten in the past by the brain-dead way that MS handles
directory structures. Parent (and grandparent, etc) directories with
large numbers of entries can effect access times for files.

I don't know if they have fixed that recently, but it used to be the
bane of my existence.

G. Wade

--
C++ tries to guard against Murphy, not Machiavelli.
-- Damian Conway

On Wed, 11 Feb 2015 12:13:53 -0500
Marius Kintel marius@kintel.net wrote:

Probably not if you are dealing with tens or hundreds of files only and
those files are currently in use or regularly accessed. All the stat data
will be cached in memory. The one exception would be networked file
stores (where generally notifiers don't work anyway).

If you are opening the files to re-check them then depending upon the OS
and the configuration you may well cause disk writes (updating last
accessed times), which if they spin the disk up can add odd delays.

Alan

On Feb 11, 2015, at 12:47 PM, nop head nop.head@gmail.com wrote:

That’s a slight improvement. We didn’t improve core CSG performance, so your render() statements will still take significant time.

It’s because you have a long piece of filament sticking out. As we don’t know the exact bounding box in preview mode, we limit the bounding box to the positive objects in the scene. If you reduce your spool_holder.spool_assembly.tube_length to e.g. 250, you’ll get a better fit.

Ouch - that sounds like a bug. Do you have a way of reproducing this with a minimal example?
I might be able to do this myself, but it might be a lot of second-guessing to get there.

Thanks for testing!

-Marius

2014.03 is more like the older versions. It slows a bit when auto reload is
on. If you keep the mouse moving it seems to keep rendering. If you pause
it can have a delay starting again.

This is on XP 32. As far as I remember I can stat hundreds of files per
second on the local disk.

On 11 February 2015 at 17:47, nop head nop.head@gmail.com wrote:

Perhaps do them one at a time in the idle loop and then it would have no
impact on the GUI but scan them just as fast when it was idle. I vaguely
remember doing that when I had to check the state of lots of networked
files for a Windows app that had to notice them change and read them and
process the data.

The long tube sticking out of the top of the Mendel90 is actually cut off
with a difference here
https://github.com/nophead/Mendel90/blob/master/scad/spool_holder.scad#L385.
It is just a trick so the correct length appears on the BOM but a truncated
version in the view. I don't know an easy way of bending into the correct
shape to meet the extruder. It should not be visible past the cut but it is
in a ghostly form for some reason. I can see why it affects the view all
regardless of whether it is visible.

I will have look at the open issue again tomorrow. I may have confused
myself.

On 11 February 2015 at 18:53, Marius Kintel marius@kintel.net wrote:

One thought that occurs to me: Mendel90 has about 80 scad files and the
main.scad depends on them all directly or indirectly. All the files that
define printed parts include a config file that also includes all the
vitamins and utilities, so they are included indirectly over and over
again. A naive tree explorer or data structure could end up stat()ing the
same files over and over again. A DAG type approach like make uses is
needed to ensure each file is only stat()ed  once per pass. I haven't
looked at your source code but it could explain big delays if it is doing
many hundred stats instead of 80.

On 11 February 2015 at 20:24, nop head nop.head@gmail.com wrote: