Module caching

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Module caching

thehans
The code is in:  Tree::getIdString, which calls to NodeDumper class to dump the whole tree into a string.

On Mon, Jan 28, 2019 at 4:21 PM nop head <[hidden email]> 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 <[hidden email]> wrote:
Ah I see. Thanks for your information. That explains a lot and it looks like
values are indeed parsed from string representation as nophead had supposed.




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

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Module caching

nophead
Sort of makes sense for scalar arguments but to dump list contents of list arguments is bonkers. Perhaps the memory address of the list, since it is the same list used 100 times?

On Mon, 28 Jan 2019 at 22:46, Hans L <[hidden email]> wrote:
The code is in:  Tree::getIdString, which calls to NodeDumper class to dump the whole tree into a string.

On Mon, Jan 28, 2019 at 4:21 PM nop head <[hidden email]> 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 <[hidden email]> wrote:
Ah I see. Thanks for your information. That explains a lot and it looks like
values are indeed parsed from string representation as nophead had supposed.




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

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Module caching

thehans
OK, I finished up working out the bugs and made my pull request re: tessellation: https://github.com/openscad/openscad/pull/2738

Between that and the progress bar changes ( https://github.com/openscad/openscad/pull/2735 ) I had to bump up the spring count to get some more precision from the rendering time.  It's gone from 26s to 16s, for a 20x20 grid of your springs.

Yeah there is probably still some performance to be gained from optimizing the cache id strings in some way, i'm not sure referencing memory addresses would be the most reliable approach, but I'll look into where its spending cycles on that front.



On Mon, Jan 28, 2019 at 5:44 PM nop head <[hidden email]> wrote:
Sort of makes sense for scalar arguments but to dump list contents of list arguments is bonkers. Perhaps the memory address of the list, since it is the same list used 100 times?

On Mon, 28 Jan 2019 at 22:46, Hans L <[hidden email]> wrote:
The code is in:  Tree::getIdString, which calls to NodeDumper class to dump the whole tree into a string.

On Mon, Jan 28, 2019 at 4:21 PM nop head <[hidden email]> 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 <[hidden email]> wrote:
Ah I see. Thanks for your information. That explains a lot and it looks like
values are indeed parsed from string representation as nophead had supposed.




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

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Module caching

thehans
I've updated my PR with another optimization related to how strings are generated for long lists, and I've now got it down to 9s for 20x20 grid of springs.

On Mon, Jan 28, 2019 at 8:00 PM Hans L <[hidden email]> wrote:
OK, I finished up working out the bugs and made my pull request re: tessellation: https://github.com/openscad/openscad/pull/2738

Between that and the progress bar changes ( https://github.com/openscad/openscad/pull/2735 ) I had to bump up the spring count to get some more precision from the rendering time.  It's gone from 26s to 16s, for a 20x20 grid of your springs.

Yeah there is probably still some performance to be gained from optimizing the cache id strings in some way, i'm not sure referencing memory addresses would be the most reliable approach, but I'll look into where its spending cycles on that front.



On Mon, Jan 28, 2019 at 5:44 PM nop head <[hidden email]> wrote:
Sort of makes sense for scalar arguments but to dump list contents of list arguments is bonkers. Perhaps the memory address of the list, since it is the same list used 100 times?

On Mon, 28 Jan 2019 at 22:46, Hans L <[hidden email]> wrote:
The code is in:  Tree::getIdString, which calls to NodeDumper class to dump the whole tree into a string.

On Mon, Jan 28, 2019 at 4:21 PM nop head <[hidden email]> 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 <[hidden email]> wrote:
Ah I see. Thanks for your information. That explains a lot and it looks like
values are indeed parsed from string representation as nophead had supposed.




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

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Module caching

nophead
Great although it only went from 22 to 17 seconds for me for 100 springs. 400 takes 70 seconds. I used the 64 bit MXE version here: https://circleci.com/gh/openscad/openscad/1350#artifacts

I was willing to believe you had a machine three times faster, due to faster memory / bus, etc but 8 times faster is a bit extreme. I do notice that the test suite runs a lot faster on the server than it does on my desktop at home. I assumed that cloud servers are somewhat more powerful. I wonder of the Linux version is faster for some reason.

On Tue, 29 Jan 2019 at 06:12, Hans L <[hidden email]> wrote:
I've updated my PR with another optimization related to how strings are generated for long lists, and I've now got it down to 9s for 20x20 grid of springs.

On Mon, Jan 28, 2019 at 8:00 PM Hans L <[hidden email]> wrote:
OK, I finished up working out the bugs and made my pull request re: tessellation: https://github.com/openscad/openscad/pull/2738

Between that and the progress bar changes ( https://github.com/openscad/openscad/pull/2735 ) I had to bump up the spring count to get some more precision from the rendering time.  It's gone from 26s to 16s, for a 20x20 grid of your springs.

Yeah there is probably still some performance to be gained from optimizing the cache id strings in some way, i'm not sure referencing memory addresses would be the most reliable approach, but I'll look into where its spending cycles on that front.



On Mon, Jan 28, 2019 at 5:44 PM nop head <[hidden email]> wrote:
Sort of makes sense for scalar arguments but to dump list contents of list arguments is bonkers. Perhaps the memory address of the list, since it is the same list used 100 times?

On Mon, 28 Jan 2019 at 22:46, Hans L <[hidden email]> wrote:
The code is in:  Tree::getIdString, which calls to NodeDumper class to dump the whole tree into a string.

On Mon, Jan 28, 2019 at 4:21 PM nop head <[hidden email]> 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 <[hidden email]> wrote:
Ah I see. Thanks for your information. That explains a lot and it looks like
values are indeed parsed from string representation as nophead had supposed.




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

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Module caching

thehans
Hmm, it appears so.  I finally dual booted into Windows 10 on my same computer that I tested the linux builds on.  

The circle-ci build gives me 18s for 100, and 73s for 400 springs, so pretty much the same results you are getting.

I was looking into what profiling tools are available for windows, and it looks like Windows Performance Analyzer (WPA) would be able to do what I want.  I particularly like viewing flame graphs; that is what I've used to analyze Linux performance, and those are available through WPA.  Unfortunately I hadn't booted into windows on this machine for what looks like 22 months and its been running updates for the past 8 hours.  It won't let me install WPA until I've updated to a more recent version, so I'm just waiting...  


On Tue, Jan 29, 2019 at 4:11 AM nop head <[hidden email]> wrote:
Great although it only went from 22 to 17 seconds for me for 100 springs. 400 takes 70 seconds. I used the 64 bit MXE version here: https://circleci.com/gh/openscad/openscad/1350#artifacts

I was willing to believe you had a machine three times faster, due to faster memory / bus, etc but 8 times faster is a bit extreme. I do notice that the test suite runs a lot faster on the server than it does on my desktop at home. I assumed that cloud servers are somewhat more powerful. I wonder of the Linux version is faster for some reason.

On Tue, 29 Jan 2019 at 06:12, Hans L <[hidden email]> wrote:
I've updated my PR with another optimization related to how strings are generated for long lists, and I've now got it down to 9s for 20x20 grid of springs.

On Mon, Jan 28, 2019 at 8:00 PM Hans L <[hidden email]> wrote:
OK, I finished up working out the bugs and made my pull request re: tessellation: https://github.com/openscad/openscad/pull/2738

Between that and the progress bar changes ( https://github.com/openscad/openscad/pull/2735 ) I had to bump up the spring count to get some more precision from the rendering time.  It's gone from 26s to 16s, for a 20x20 grid of your springs.

Yeah there is probably still some performance to be gained from optimizing the cache id strings in some way, i'm not sure referencing memory addresses would be the most reliable approach, but I'll look into where its spending cycles on that front.



On Mon, Jan 28, 2019 at 5:44 PM nop head <[hidden email]> wrote:
Sort of makes sense for scalar arguments but to dump list contents of list arguments is bonkers. Perhaps the memory address of the list, since it is the same list used 100 times?

On Mon, 28 Jan 2019 at 22:46, Hans L <[hidden email]> wrote:
The code is in:  Tree::getIdString, which calls to NodeDumper class to dump the whole tree into a string.

On Mon, Jan 28, 2019 at 4:21 PM nop head <[hidden email]> 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 <[hidden email]> wrote:
Ah I see. Thanks for your information. That explains a lot and it looks like
values are indeed parsed from string representation as nophead had supposed.




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

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Module caching

thehans
OK I've had a hell of a time getting the updates to install and just given up on using Windows on that machine for now.  It would have been nice to compare on the same hardware, but I've just decided to do some more testing on my main windows machine that is already properly updated.  
I got WPR and WPA installed, but don't have debug symbols in the circle-ci builds so the flame graph stack listings are useless to me at the moment.  I'm not sure how to create a debug windows build yet, I'll look into that.  

I was able to test the AppImage to under windows, by more or less following these instructions: https://discourse.appimage.org/t/run-appimage-on-windows/177
I used Debian linux from Microsoft Store, and also had to install a couple more packages:
sudo apt install xcb libgtk2.0-0 libgl1-mesa-glx 

It does 100 springs in 2s and 400 in 10s, which is basically the same results I was seeing from native linux.


On Tue, Jan 29, 2019 at 9:56 PM Hans L <[hidden email]> wrote:
Hmm, it appears so.  I finally dual booted into Windows 10 on my same computer that I tested the linux builds on.  

The circle-ci build gives me 18s for 100, and 73s for 400 springs, so pretty much the same results you are getting.

I was looking into what profiling tools are available for windows, and it looks like Windows Performance Analyzer (WPA) would be able to do what I want.  I particularly like viewing flame graphs; that is what I've used to analyze Linux performance, and those are available through WPA.  Unfortunately I hadn't booted into windows on this machine for what looks like 22 months and its been running updates for the past 8 hours.  It won't let me install WPA until I've updated to a more recent version, so I'm just waiting...  


On Tue, Jan 29, 2019 at 4:11 AM nop head <[hidden email]> wrote:
Great although it only went from 22 to 17 seconds for me for 100 springs. 400 takes 70 seconds. I used the 64 bit MXE version here: https://circleci.com/gh/openscad/openscad/1350#artifacts

I was willing to believe you had a machine three times faster, due to faster memory / bus, etc but 8 times faster is a bit extreme. I do notice that the test suite runs a lot faster on the server than it does on my desktop at home. I assumed that cloud servers are somewhat more powerful. I wonder of the Linux version is faster for some reason.

On Tue, 29 Jan 2019 at 06:12, Hans L <[hidden email]> wrote:
I've updated my PR with another optimization related to how strings are generated for long lists, and I've now got it down to 9s for 20x20 grid of springs.

On Mon, Jan 28, 2019 at 8:00 PM Hans L <[hidden email]> wrote:
OK, I finished up working out the bugs and made my pull request re: tessellation: https://github.com/openscad/openscad/pull/2738

Between that and the progress bar changes ( https://github.com/openscad/openscad/pull/2735 ) I had to bump up the spring count to get some more precision from the rendering time.  It's gone from 26s to 16s, for a 20x20 grid of your springs.

Yeah there is probably still some performance to be gained from optimizing the cache id strings in some way, i'm not sure referencing memory addresses would be the most reliable approach, but I'll look into where its spending cycles on that front.



On Mon, Jan 28, 2019 at 5:44 PM nop head <[hidden email]> wrote:
Sort of makes sense for scalar arguments but to dump list contents of list arguments is bonkers. Perhaps the memory address of the list, since it is the same list used 100 times?

On Mon, 28 Jan 2019 at 22:46, Hans L <[hidden email]> wrote:
The code is in:  Tree::getIdString, which calls to NodeDumper class to dump the whole tree into a string.

On Mon, Jan 28, 2019 at 4:21 PM nop head <[hidden email]> 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 <[hidden email]> wrote:
Ah I see. Thanks for your information. That explains a lot and it looks like
values are indeed parsed from string representation as nophead had supposed.




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

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Module caching

thehans
Progress!

I managed to figure out that most of the process time is spent in msvcrt.dll!setlocale
Still don't have OpenSCAD symbols to show what part of OpenSCAD is invoking this so much, but I found that going into OpenSCAD Preferences -> Advanced, and disabling "Enabled user interface localization" (then restart OpenSCAD) makes it fast again!


On Wed, Jan 30, 2019 at 3:00 PM Hans L <[hidden email]> wrote:
OK I've had a hell of a time getting the updates to install and just given up on using Windows on that machine for now.  It would have been nice to compare on the same hardware, but I've just decided to do some more testing on my main windows machine that is already properly updated.  
I got WPR and WPA installed, but don't have debug symbols in the circle-ci builds so the flame graph stack listings are useless to me at the moment.  I'm not sure how to create a debug windows build yet, I'll look into that.  

I was able to test the AppImage to under windows, by more or less following these instructions: https://discourse.appimage.org/t/run-appimage-on-windows/177
I used Debian linux from Microsoft Store, and also had to install a couple more packages:
sudo apt install xcb libgtk2.0-0 libgl1-mesa-glx 

It does 100 springs in 2s and 400 in 10s, which is basically the same results I was seeing from native linux.


On Tue, Jan 29, 2019 at 9:56 PM Hans L <[hidden email]> wrote:
Hmm, it appears so.  I finally dual booted into Windows 10 on my same computer that I tested the linux builds on.  

The circle-ci build gives me 18s for 100, and 73s for 400 springs, so pretty much the same results you are getting.

I was looking into what profiling tools are available for windows, and it looks like Windows Performance Analyzer (WPA) would be able to do what I want.  I particularly like viewing flame graphs; that is what I've used to analyze Linux performance, and those are available through WPA.  Unfortunately I hadn't booted into windows on this machine for what looks like 22 months and its been running updates for the past 8 hours.  It won't let me install WPA until I've updated to a more recent version, so I'm just waiting...  


On Tue, Jan 29, 2019 at 4:11 AM nop head <[hidden email]> wrote:
Great although it only went from 22 to 17 seconds for me for 100 springs. 400 takes 70 seconds. I used the 64 bit MXE version here: https://circleci.com/gh/openscad/openscad/1350#artifacts

I was willing to believe you had a machine three times faster, due to faster memory / bus, etc but 8 times faster is a bit extreme. I do notice that the test suite runs a lot faster on the server than it does on my desktop at home. I assumed that cloud servers are somewhat more powerful. I wonder of the Linux version is faster for some reason.

On Tue, 29 Jan 2019 at 06:12, Hans L <[hidden email]> wrote:
I've updated my PR with another optimization related to how strings are generated for long lists, and I've now got it down to 9s for 20x20 grid of springs.

On Mon, Jan 28, 2019 at 8:00 PM Hans L <[hidden email]> wrote:
OK, I finished up working out the bugs and made my pull request re: tessellation: https://github.com/openscad/openscad/pull/2738

Between that and the progress bar changes ( https://github.com/openscad/openscad/pull/2735 ) I had to bump up the spring count to get some more precision from the rendering time.  It's gone from 26s to 16s, for a 20x20 grid of your springs.

Yeah there is probably still some performance to be gained from optimizing the cache id strings in some way, i'm not sure referencing memory addresses would be the most reliable approach, but I'll look into where its spending cycles on that front.



On Mon, Jan 28, 2019 at 5:44 PM nop head <[hidden email]> wrote:
Sort of makes sense for scalar arguments but to dump list contents of list arguments is bonkers. Perhaps the memory address of the list, since it is the same list used 100 times?

On Mon, 28 Jan 2019 at 22:46, Hans L <[hidden email]> wrote:
The code is in:  Tree::getIdString, which calls to NodeDumper class to dump the whole tree into a string.

On Mon, Jan 28, 2019 at 4:21 PM nop head <[hidden email]> 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 <[hidden email]> wrote:
Ah I see. Thanks for your information. That explains a lot and it looks like
values are indeed parsed from string representation as nophead had supposed.




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

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Module caching

nophead
Amazing. I turned that off and goes about 3 times faster, so 7 seconds before your mod and 5 seconds after it. 18 seconds for 400

On Wed, 30 Jan 2019 at 23:28, Hans L <[hidden email]> wrote:
Progress!

I managed to figure out that most of the process time is spent in msvcrt.dll!setlocale
Still don't have OpenSCAD symbols to show what part of OpenSCAD is invoking this so much, but I found that going into OpenSCAD Preferences -> Advanced, and disabling "Enabled user interface localization" (then restart OpenSCAD) makes it fast again!


On Wed, Jan 30, 2019 at 3:00 PM Hans L <[hidden email]> wrote:
OK I've had a hell of a time getting the updates to install and just given up on using Windows on that machine for now.  It would have been nice to compare on the same hardware, but I've just decided to do some more testing on my main windows machine that is already properly updated.  
I got WPR and WPA installed, but don't have debug symbols in the circle-ci builds so the flame graph stack listings are useless to me at the moment.  I'm not sure how to create a debug windows build yet, I'll look into that.  

I was able to test the AppImage to under windows, by more or less following these instructions: https://discourse.appimage.org/t/run-appimage-on-windows/177
I used Debian linux from Microsoft Store, and also had to install a couple more packages:
sudo apt install xcb libgtk2.0-0 libgl1-mesa-glx 

It does 100 springs in 2s and 400 in 10s, which is basically the same results I was seeing from native linux.


On Tue, Jan 29, 2019 at 9:56 PM Hans L <[hidden email]> wrote:
Hmm, it appears so.  I finally dual booted into Windows 10 on my same computer that I tested the linux builds on.  

The circle-ci build gives me 18s for 100, and 73s for 400 springs, so pretty much the same results you are getting.

I was looking into what profiling tools are available for windows, and it looks like Windows Performance Analyzer (WPA) would be able to do what I want.  I particularly like viewing flame graphs; that is what I've used to analyze Linux performance, and those are available through WPA.  Unfortunately I hadn't booted into windows on this machine for what looks like 22 months and its been running updates for the past 8 hours.  It won't let me install WPA until I've updated to a more recent version, so I'm just waiting...  


On Tue, Jan 29, 2019 at 4:11 AM nop head <[hidden email]> wrote:
Great although it only went from 22 to 17 seconds for me for 100 springs. 400 takes 70 seconds. I used the 64 bit MXE version here: https://circleci.com/gh/openscad/openscad/1350#artifacts

I was willing to believe you had a machine three times faster, due to faster memory / bus, etc but 8 times faster is a bit extreme. I do notice that the test suite runs a lot faster on the server than it does on my desktop at home. I assumed that cloud servers are somewhat more powerful. I wonder of the Linux version is faster for some reason.

On Tue, 29 Jan 2019 at 06:12, Hans L <[hidden email]> wrote:
I've updated my PR with another optimization related to how strings are generated for long lists, and I've now got it down to 9s for 20x20 grid of springs.

On Mon, Jan 28, 2019 at 8:00 PM Hans L <[hidden email]> wrote:
OK, I finished up working out the bugs and made my pull request re: tessellation: https://github.com/openscad/openscad/pull/2738

Between that and the progress bar changes ( https://github.com/openscad/openscad/pull/2735 ) I had to bump up the spring count to get some more precision from the rendering time.  It's gone from 26s to 16s, for a 20x20 grid of your springs.

Yeah there is probably still some performance to be gained from optimizing the cache id strings in some way, i'm not sure referencing memory addresses would be the most reliable approach, but I'll look into where its spending cycles on that front.



On Mon, Jan 28, 2019 at 5:44 PM nop head <[hidden email]> wrote:
Sort of makes sense for scalar arguments but to dump list contents of list arguments is bonkers. Perhaps the memory address of the list, since it is the same list used 100 times?

On Mon, 28 Jan 2019 at 22:46, Hans L <[hidden email]> wrote:
The code is in:  Tree::getIdString, which calls to NodeDumper class to dump the whole tree into a string.

On Mon, Jan 28, 2019 at 4:21 PM nop head <[hidden email]> 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 <[hidden email]> wrote:
Ah I see. Thanks for your information. That explains a lot and it looks like
values are indeed parsed from string representation as nophead had supposed.




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

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Module caching

nophead
Now down to 2 seconds for 100 and 8 seconds for 400 with your latest double optimisation. So altogether a 50 times speed improvement, very impressive, thanks.

On Thu, 31 Jan 2019 at 00:04, nop head <[hidden email]> wrote:
Amazing. I turned that off and goes about 3 times faster, so 7 seconds before your mod and 5 seconds after it. 18 seconds for 400

On Wed, 30 Jan 2019 at 23:28, Hans L <[hidden email]> wrote:
Progress!

I managed to figure out that most of the process time is spent in msvcrt.dll!setlocale
Still don't have OpenSCAD symbols to show what part of OpenSCAD is invoking this so much, but I found that going into OpenSCAD Preferences -> Advanced, and disabling "Enabled user interface localization" (then restart OpenSCAD) makes it fast again!


On Wed, Jan 30, 2019 at 3:00 PM Hans L <[hidden email]> wrote:
OK I've had a hell of a time getting the updates to install and just given up on using Windows on that machine for now.  It would have been nice to compare on the same hardware, but I've just decided to do some more testing on my main windows machine that is already properly updated.  
I got WPR and WPA installed, but don't have debug symbols in the circle-ci builds so the flame graph stack listings are useless to me at the moment.  I'm not sure how to create a debug windows build yet, I'll look into that.  

I was able to test the AppImage to under windows, by more or less following these instructions: https://discourse.appimage.org/t/run-appimage-on-windows/177
I used Debian linux from Microsoft Store, and also had to install a couple more packages:
sudo apt install xcb libgtk2.0-0 libgl1-mesa-glx 

It does 100 springs in 2s and 400 in 10s, which is basically the same results I was seeing from native linux.


On Tue, Jan 29, 2019 at 9:56 PM Hans L <[hidden email]> wrote:
Hmm, it appears so.  I finally dual booted into Windows 10 on my same computer that I tested the linux builds on.  

The circle-ci build gives me 18s for 100, and 73s for 400 springs, so pretty much the same results you are getting.

I was looking into what profiling tools are available for windows, and it looks like Windows Performance Analyzer (WPA) would be able to do what I want.  I particularly like viewing flame graphs; that is what I've used to analyze Linux performance, and those are available through WPA.  Unfortunately I hadn't booted into windows on this machine for what looks like 22 months and its been running updates for the past 8 hours.  It won't let me install WPA until I've updated to a more recent version, so I'm just waiting...  


On Tue, Jan 29, 2019 at 4:11 AM nop head <[hidden email]> wrote:
Great although it only went from 22 to 17 seconds for me for 100 springs. 400 takes 70 seconds. I used the 64 bit MXE version here: https://circleci.com/gh/openscad/openscad/1350#artifacts

I was willing to believe you had a machine three times faster, due to faster memory / bus, etc but 8 times faster is a bit extreme. I do notice that the test suite runs a lot faster on the server than it does on my desktop at home. I assumed that cloud servers are somewhat more powerful. I wonder of the Linux version is faster for some reason.

On Tue, 29 Jan 2019 at 06:12, Hans L <[hidden email]> wrote:
I've updated my PR with another optimization related to how strings are generated for long lists, and I've now got it down to 9s for 20x20 grid of springs.

On Mon, Jan 28, 2019 at 8:00 PM Hans L <[hidden email]> wrote:
OK, I finished up working out the bugs and made my pull request re: tessellation: https://github.com/openscad/openscad/pull/2738

Between that and the progress bar changes ( https://github.com/openscad/openscad/pull/2735 ) I had to bump up the spring count to get some more precision from the rendering time.  It's gone from 26s to 16s, for a 20x20 grid of your springs.

Yeah there is probably still some performance to be gained from optimizing the cache id strings in some way, i'm not sure referencing memory addresses would be the most reliable approach, but I'll look into where its spending cycles on that front.



On Mon, Jan 28, 2019 at 5:44 PM nop head <[hidden email]> wrote:
Sort of makes sense for scalar arguments but to dump list contents of list arguments is bonkers. Perhaps the memory address of the list, since it is the same list used 100 times?

On Mon, 28 Jan 2019 at 22:46, Hans L <[hidden email]> wrote:
The code is in:  Tree::getIdString, which calls to NodeDumper class to dump the whole tree into a string.

On Mon, Jan 28, 2019 at 4:21 PM nop head <[hidden email]> 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 <[hidden email]> wrote:
Ah I see. Thanks for your information. That explains a lot and it looks like
values are indeed parsed from string representation as nophead had supposed.




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

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
12