2015.02.05 less responsive
On Feb 11, 2015, at 12:47 PM, nop head nop.head@gmail.com wrote:
2015.02 reduces the first render time from 20 minutes 27 to 17 minutes 20 second, which is worth having.
That’s a slight improvement. We didn’t improve core CSG performance, so your render() statements will still take significant time.
The view all seems to shrink the Mendel90 excessively, perhaps because it is tall and thin.
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.
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.
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:
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:
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:
On Feb 11, 2015, at 12:16 PM, nop head nop.head@gmail.com wrote:
I have never updated from 2013.06 because it does everything I need.
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
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
We’re only doing stat() calls on the dependent filenames, so I agree that this sounds a bit fishy.
I’ll have to profile this to see if we’re inadvertently triggering any processing or other I/O.
-Marius
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:
We're only doing stat() calls on the dependent filenames, so I agree that
this sounds a bit fishy.
I'll have to profile this to see if we're inadvertently triggering any
processing or other I/O.
-Marius
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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:
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:
We're only doing stat() calls on the dependent filenames, so I agree that
this sounds a bit fishy.
I'll have to profile this to see if we're inadvertently triggering any
processing or other I/O.
-Marius
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
FYI: https://github.com/openscad/openscad/issues/1237
-Marius