@slbaumgartner said:
No 3D geometry model editing program has cracked this nut in at least two decades. There are fundamental computer science reasons why it regarded as essentially impossible. So, don't hold your breath!
I'm fully aware that it wouldn't be possible for all operations (at least at the moment) But why not use it for tasks that can be multi-threaded, like background saving or file import/export, rendering, etc.?
Examples:
Revit https://knowledge.autodesk.com/support/revit-products/troubleshooting/caas/sfdcarticles/sfdcarticles/Which-function-in-Revit-will-take-use-of-multiple-processors.html
ArchiCAD http://helpcenter.graphisoft.com/technotes/setup/software-technologies/multiprocessing-and-archicad/#Is_ArchiCAD_multi-threaded
Invertor https://knowledge.autodesk.com/support/inventor-products/troubleshooting/caas/sfdcarticles/sfdcarticles/Support-for-multi-core-processors.html
Some 3DSmax modifiers are already threaded (Bend, Skin, SkinWrap, Shell, PFlow, APEX Clothing, Delta Mush to Skin, etc.)
Not sure about Maya... i know that Maya API supports multi threading
cinema4d https://www.maxon.net/en/news/maxon-news/article/foundations-for-the-future/
Siemens NX (Parasolid) http://cadabout.ru/2016/10/28/a-few-words-about-siemens-nx-perfomance-cpu-graphic-adapter-memory-multi-core/
Grasshopper https://stevebaer.wordpress.com/2013/12/11/ghpython-node-in-code/
If there are better ways to improve the performance single threaded - no problem.
@slbaumgartner said:
In some ways this proposal is like the one a few years ago about the need for 64-bit support. They added it, and it turns out the pundits were right: the only real benefit was ability to use more memory for large models. It did not have a noticeable effect on the performance of SU.
I never said that 64bit would improve performance. But i can say that i experienced many crashes hitting the memory limit. Trust me... i know why i voted for 64bit 
@slbaumgartner said:
There is nothing the SU team can do about the basic execution speed of Ruby. They do not develop the Ruby interpreter, they just embed it within SketchUp. Ruby is not designed as or advertised as a high-performance language.
If that's really the case and they are already at the limit of what ruby is capable to deliver, then i think they should rethink their "strategy" of relying completely on ruby code for standard operations like rounding edges or processing SUbD models.
(Btw. as far as i know it's also possible to multi-thread Ruby code. I don't know about the SU implementation. https://www.tutorialspoint.com/ruby/ruby_multithreading.htm)
@slbaumgartner said:
I suppose there could be further optimizations in the SketchUp Ruby API (which is the gateway between Ruby code and underlying compiled SketchUp code). For example, new methods that hand off more bulk operations to the compiled library instead of using Ruby step-by-step logic. Other apps get their speed by having these operations done by compiled code, not by a scripting language such as Ruby.
Sophisticated programmers write the performance-critical parts of their extensions in compiled C/C++ code, which is much faster than Ruby. But they must still route their access to the SU model and library through the Ruby API bridge. They are compiled extensions to Ruby, not really compiled extension to SU itself. It isn't clear how much overhead that adds, but perhaps there could be a C/C++ API to bypass Ruby entirely (note: the existing SDK does not do so, it is for reading and writing SU files independent of the SU process).
Like i said above, if it's not possible to speed up Ruby scripts, i think Trimble should do anything to either support the developers of these critical functions or implement them directly into the SU code.
)
