Hello,
just found strange performance issue in the javascript engine.
Here is test file, and two scripts which changes style of all objects. Both scripts are exactly the same, but second uses execCommand function to run.

test1.js

var t = new Date(); var obj = moi.geometryDatabase.getObjects();  for ( var i = 0; i < obj.length; i++) obj.item(i).styleIndex = 1; moi.log("test1: "+(new Date() - t) / 1000 + " seconds\r");

test2.js

moi.command.execCommand ('var t = new Date(); var obj = moi.geometryDatabase.getObjects();  for ( var i = 0; i < obj.length; i++) obj.item(i).styleIndex = 2; moi.log("test2: "+(new Date() - t) / 1000 + " seconds\\r");');

Log:

test1: 6.651 seconds   <--- ????  >:-[
test2: 0.002 seconds

Look at this. Why the plain script takes much more time to run?

The one using execCommand is actually not being run as a "command", it's being run as inline script code.

Inline script is run on the main thread inside of the main process. That means that every call to a MoI object happens as a direct function call which is efficient.

Script code that is running inside of a "command" runs in a separate process called moi_commandprocessor.exe, and that means it has to do inter-process communication every time it communicates with a MoI object that lives inside of the main moi.exe process. This interprocess communication has a fair amount of overhead in it - it's not bad when it's just executing a straight linear sequence of code but it can add up a lot if you have the script doing heavier processing with loops and things like that.

The reason why a regular command runs in a separate process is for general robustness and UI responsiveness - when you run script code on the main thread while that code is executing you won't see MoI doing anything else at all, like not responding to mouse clicks or redrawing its window or things like that, and if your code goes into a infinite loop it will lock up moi completely. These things won't happen when the code is primarily running in a separate process and only communicating to MoI for individual method calls.

Another way you can get your script code to run in the main process is if your command has a companion .htm file for its UI, any script code that's declared in the .htm file will run in the main process too.

- Michael

I recollect that debugging is harder with the faster method, because the error messages do not occur if the code has errors...
(Or something like that :-)

http://moi3d.com/forum/index.php?webtag=MOI&msg=5878.18

- Brian

>>any script code that's declared in the .htm file will run in the main process too
Great!! Thank you for the hint! Now it works very fast.

I am writing script which generates multiscatter data for Octane render. It's very handy to use MoI for this purpose. But I need to process huge amount of data in short time (100000 - 300000 points). Now it will work even faster than before. :) I'll finish it in couple days.

This is a test renders. Both scenes created in MoI. I spent 30 minutes making this.
First one: 6 objects, ~10000 instances. Second: 1 object, ~7000 instances.

Brian, thank you.
Sometimes I used this trick before, but I never thought about performance differences.

P.S. And thank you for your scripts! :)
I used Harmonic Trefoil script in this test.

Nice looking results, Max!

I have some ideas for the future on how to try and make "out of process" scripts run faster, something like move objects that the script wants to access over into the worker process so that the script can have local access to them, and then after the script has done all its processing work move the results back into the main process. That's basically how an async "geometry factory" works right now but with C++ code.

- Michael

Thank you, Michael!

>>.. like move objects that the script wants to access over into the worker process so that the script can have local access to them..
Very good idea! It will really help.
I checked the performance and found that the bottleneck in my script are getStartPt and getEndPt functions (only 900 segments per second, while script can process about 1500 segments per second).
The overall performance is ~600 instances per second.
Tomorrow I will move some functions to htm file.

Unbelievable!
I've got more than 10x boost!!

Normal mode:


Without 3D transformations: