Mel Vs Api

[udayan-2]

Hi

I am wodnering if there are any performance values to compare mel implementation vs API implementation in Maya. How fast can plugin implementation get over the same functionality implemented in MEL.

I understand this will depend on the complexity of the problem at hand, but in general, a rough idea, min/max estiamtes of performance enhancements?

Thanks

Uday

[daniel-faust]

The API documentation and the book "Complete Maya Programming" say that the C++ can be up to ten times faster on complex programs, some other may not be faster at all.

[joojaa]

Some operations are even faster than 10 times (some are slower than mel because of badly doen api plugs) but the bottom line is how often do you need the tool. I mena if you do it daily and it takes mel 1-10 seconds to do then you can probably say that:

your mel code developement time is X
your api code development time is 2-50*X

now if you run this script once every day and you get the 10 x nboost you win 9 seconds every day!

now that means you win 38 and a half minutes over he course of a year. Now say you have a development time of 3 hours in mel that would mean that youd be looking at 6 hours minimum developping the api code. now thats 3 hours more to work. Wich means the api implementation becomes viable in 4.6 years of continious use. So bottom line is its not worth it in this case.

However whan you start developping something thats interactive then ist switches oevr since mel might find it mpossible or extremely hard to do at acceptable speeds. However theres lot the nodes can do, so investigate them first. Also design flexible nodes, since flexibility wins over pure performance most of the time!

Now theres one additional overhead in api code, and ist that it takes MUCH more time to maintain between versiions! Also it harder to deploy.

then theres the fact that getting into the api is a much huger ivestment than getting realy into mel!!

[scratch]

You can make this experience to compare speed between mel and api ...

Animate an object's translation on a quite long range of time, depending on your computer's performance. Then create a second object. The aim is to copy the first object's animation to the second one, by getting the value of the first object, then setting it on the second object, then keying the second object at each frame.

Do this using mel first, then do the same using api. The difference is incredible !

[joojaa]

QUOTE(scratch @ 09/21/05, 02:41 PM)
Do this using mel first, then do the same using api. The difference is incredible ! 
[snapback]215305[/snapback]

Yeah sure... but who the hell would do thiskind of stupid mel? Mel isnt realy a EVALUATOR like this, expressions are even in api its not a good idea to step trough time like this. Mel hats 2 different appraches for stuff.

One mel is to build and modify node networks. pople still think your doing mel even if you employ a node to do your job. Theres nothing worng with this since in the end this is what maya does with mel. Tough in reality it isnt

Second is to querry stuff. NOW mel is a bit fickle here. if youd posted the codes on what you compared then id show ways to boost the mel up by a significant amount.

BUt mel is definetly NOT soemthing you call every frame, you can but ist totaly stupid. Mel isnt a dg iterator nodes are. MEl has facities to build node enetworks for this.

and yes i compared this and my api stuff was 0.0001 seconds fater than the mel one!

se theres realy soem things in mel thats NOT definetly what most programmers thisnk is what they ought to do. for example stepping trough time in mel is HORRIBLY expensive. tehnagain if youd do this as a expression it owuld be wquite fast... if you do a aim constraint again would be as fast asyour api code all whithin mel.

But if you realy realy want a perverted melcode then yto optimize it you woudlt step per frame, becaus ethet would be supid form mels point of view. youd querry the entire sample are with one comand then calc and spit a out curve wiith one.

BUT the bottom line mel is definetly not the tool for this in the way you think it is.

[scratch]

Come on, Joojaa ... Why so much anger ?
I never said it is a clever script, it's not ... I did that once while working on api, and that only illustrates speed difference ( not by using mel scripting in api of course ! ) I think it's nice to make experiences, even if they finally are stupid or useless ... I didn't post the script here, because you can make it in a couple of seconds.

[rob-bateman]

In defense on Joojaa here....

comparing mel and the api is really pretty pointless. mel is a journaling service and GUI language for maya - the API allows you to add new components.

In reality, if you are actually doing complex calculations or scene creation from within mel, then you seriously mis-understand how to use mel.

For example, i could decide i wanted to create a basic expression to linearly interpolate between two values. ie,

$v = (1-$t)$p0 + $t$p1;

however i could also create a colour blend node and use that to linearly interpolate the values. Not only would that be a hard coded C++ bit of code (since the evaluation is part of the nodes compute method), but you also gain the ability to cache that result since it nicely forms part of the dependency graph.

In effect, mel is very good at constructing very efficient dependency graphs to evaluate what you need - and to that effect (as joojaa said) mel is therefore able to be just as quick as the API.

Another example may be using mel to calculate an aim vector between 2 points. Wha not just use mel to create an aim-constraint then delete it ? A common mistake is that people assume that mel should be used 'just like C', when in reality it's a very different beast.

The API is only really useful for adding in specific components or operations that ARE NOT PRESENT in Maya - (and exporters....)

[joojaa]

Im not angry . im just trying to point out thet thers good and bad benchmarks, this is worse than a awfull one.

Offourse it does not demonstrate anything! Nobody would do it thet way in mel. teyd call a orient constraint and be done with it. But sure theres alott of stuff where you can do a million times or more speed preformance if you choose the example BADLY.

I mean takaing somemthing stupid to demonstrate the speed difference is well just a show that you can equaly well do inefficient mel code. Its like comparing two garphics cards with a porgram whan the other has test platform optimized drivers and the other does not. Does this mean its fater just because it got fatser benchmarks? No!

I think people have a huge misunderstanding about what mel is. But that aside i do think the question is CAN it be done efficently with mel. Yes, you can you just do a aim contraint in mel and viola it updates at api speeds! NO question about it.

SO could i do it in mel? Yes! Is it mel thats doing the stuff? No, maya is. So how long did it take for you to do code for this in api? Some doing this in mel stepping thru time is 4-8 lines of code, and works granttedly right and is fast.

NOW id say you realy cant get faster than the constraint , unless i knew for a fact that if you wanted to bake out the solution there is a fater way than stepping thru time like you do! its kindof a special case and it gets easily slower if theeres a animated hierarchy underneath tough. What you do is you fetch the anim of the target as anim curves then Interpolate them isnide yoru own code for the aim. Or even better if the keys are sparse do a full mathamatical solve on this.

Se heres the mel to create this!

CODE
{
$aim=polyCone -n aim -r 1 -h 2 -sx 20 -sy 1 -sz 0 -ax 0 1 0 -tx 1 -ch 1;
$target=sphere -n target -p 0 0 0 -ax 0 1 0 -ssw 0 -esw 360 -r 1 -d 3 -ut 0 -tol 0.01 -s 8 -nsp 4 -ch 1;
aimConstraint -offset 0 0 0 -weight 1 -aimVector 0 1 0 -upVector 1 0 0 -worldUpType "vector" -worldUpVector 0 1 0 $target[0] $aim[0];
}

Point out here theres nothing not mel here ist just that again mel is not the kind of normal do this language in this sense.

Now baking it out you could just run (i wouldnt):

CODE
bakeResults -simulation true -t "0:1000000" -sampleBy 1 -disableImplicitControl true -preserveOutsideKeys true -sparseAnimCurveBake false -at "rx" -at "ry" -at "rz" aim;

Now youd get a awfull speed! because maya would evaluate the ogl (wich in it self takes time and so if you have synchronized output you couldnt exceed the refres rate or even pert of it)! but you can squish even more speed out of this. this is a dirty way of doing it theres a more elegant one but its one line more code

So lets optimize (lets insert atimer too so we knwo how slow it is):

CODE
$startTime = timerX;
setNamedPanelLayout "Single Perspective View";
outlinerPanel -e -rp modelPanel4 outlinerPanel1;
bakeResults -simulation true -t "0:1000000" -sampleBy 1 -disableImplicitControl true -preserveOutsideKeys true -sparseAnimCurveBake false -at "rx" -at "ry" -at "rz" aim;
$totalTime = timerX -startTime $startTime;
print ("Total Time: "+$totalTime+"\n");

Conclusion

Anyway i timed how long it took me to bake out this for million frames of motion now i got 153.34 seconds (about 2 half minutes). bear in mind tough that million frames is 700 hours worth of finalized film frames so if you routinely bake this kind of stuff out it takes 0.43 seconds to bake out for a entire feature film. NOT much is it? okay unfair it took some time to generate the geoa too. Under 0.1 seconds (note i could habve disabled the ogl for this too! for more speed.).

So i generated my mel in 3 minutes ( or cut and pasted the vcode realy and wrote this post but didnt spellchek it, becaus ei dont realy have time). just compiling and loading it in to maya probably takes longer in api and for what? youd se the benefit if you routinely doiid thsi in movies for say once every day for a moth!!!!

Now is this benchmark good! HELL NO it only eveluates a few measly anim curves!

QED

Any questions?

PS. nice defense Rob much appriciated... i think i went overboard demontarting this! Dont you