[Closed] Maxscript vs SDK speed test

Not needed, which is why C# is so attractive for Max now. You can just work with any classes you create from within MXS. For example, I DLed a DLL from Codeproject to work with zip files, all I have to do it call:

zip = (dotNetClass "Ionic.Utils.Zip.ZipFile").Read(dotnetobject "system.string" zipfilename)

etc. There may be better ways to use simple functions (like your for loop) rather than as members of a static class or on an object.

Could someone with good C# skills try out this test (I’d like to see you back up your claim, Light)?

Also, reForm, as far as optimization goes- I have found that MXS’s biggest slowdown is getting and setting properties (as described here, which I think you’ve read). Be sure you need to go into C++. We wrote an entire Vertlet sim in MXS, and the math part of it was an almost negligible performance (rendering, and getting/setting properties (which we eventually moved into global array accesses and get/set properties just once, which is must faster) probably 80% of the processing time, the math maybe 5-10%).

Not a hockey fan actually. So Oilers kinda freak me out (:

I have written this code for you:

using System;
  using System.Collections.Generic;
  using System.Text;
  
  namespace LinearAlgebra
  {
  	public static class Arithmetic
  	{
  		public static double Multiply ( double a, double b )
  		{
  			double result = 0;
  
  			for ( int i = 0; i < 10000000; ++i )
  			{
  				result += (a + i) * (b - i);
  			}
  
  			return result;
  		}
  	}
  }

Just create a class library and compile it in Release mode. Then use this Maxscript code to load:

DotNet.LoadAssembly @"C:\<assemblyName.dll>"

and replace the method call with this:

result = (DotNetClass "LinearAlgebra.Arithmetic").Multiply

You can only compile as a .dll. If you can’t compile, then I can send you the dll I compiled.

Basically certain things are well optimized in the CLR. There are some guidelines as to what might be faster but for others you just judge it by experience, looking at the IL code.

I just tried it on my and got results between 15-31ms, which is mostly the cold startup overhead of the CLR.

A more accurate timing for C# would actually do some computation before the timing just to isolate the operation.

Light

Interesting stuff!

My script definately needs to leave maxscript. At the moment, its not a realtime operation, but I would like to maybe introduce realtime manipulation later once I’ve got my head into c++ (alot) more!

As it stands, the script has some bottlenecks. I’m arraying multiple objects onto multiple faces with deformations calculated based on the distribution object face shapes. The slowest part of the script is a loop where I cycle through each vertex, and then calculate the total of the averaged weights of that vertice in relation to its deformation control points. Its a simple bit of math, but the depth of the loop and number of iterations kills maxscript(speed-wise). I assume this is the kind of operation that is ideal for translating into c++ or c#?

Besides this, I may think about making my script into a proper modifier at some point as it would be a more logical form for the tool to take.

Having said all this, I must look into the c# option. You say I don’t need to create a .gup … if so how would I distribute a plugin written in c#? Install into the windows system32 folder? Apologies if I’m missing your point entirely

The resultant dll can be anywhere but preferably inside a folder under Max. I put them into <maxroot>/stdplugs/managed.

So you only have to distribute the dll itself.

But the problem with Max’s .NET integration is, it doesn’t provide a managed wrapper for Max SDK, which means you can’t write Max related stuff using C#, IronPython, VB .NET, etc.

However you can work around it by using COM, or wait for someone to release a managed wrapper for Max.

Light

Ah… so if I wanted to work on a mesh directly, I would have to do it in c++…

Have you any experience of sending massive arrays to c# functions? I could probably get away without using any max core operations if I can pass a massive array of vertex positions to and from my function.
Failing that, I’ll have to look at reading vertex positions in c and populating my arrays directly in my compiled plugin. fun fun fun.

Yes, sending massive collections from Max into C# is VERY slow. One tool we wrote here using C# and Maxscript, is instantaneous on the C# side but takes several seconds to minutes for Maxscript to send the data and get it back.

There is also the issue of killing Max when you send it all in one shot if there are millions of elements. For that you have to send in pieces (say 10000 each time).

In that case you still shouldn’t destroy the generic nature of the C# plugin IMO.

So for that I do it like this:

1. Generic code in C#
2. Max interface code in C# (that contains the specific workarounds)
3. Maxscript code

By doing that, you get the benefit of being able to use the generic managed plugin anywhere you want, say in Maya, XSI, etc.

Light

Well, here are the results. Same routine as you put in the c# code for the maxscript and c+(plugin) tests.

maxscript : 16516ms
c++ : 141ms
c# : 47ms

nice

something else you may want to consider checking out is the IntervalArray maxscript plugin example. I remember speed testing the results compared to using maxscript’s collect function and maxscript came out ahead, probably due to the collect function being so awesome. At the very least it’s something to keep in mind.

Sorry to raise this from the dead, but has anyone tried the MaxDotNet thing from Ephere? How does it compare speed wise?