Offcousre the entire code is obsolete as it already built in ![]()
QUOTE(GoLeafsGo @ 09/30/07, 03:59 AM) [snapback]274079[/snapback]
then I'd say that you should probably be looking into the API. I see this now and again where someone writes a script which loops over all selected components and they waste so much time trying to make it faster as a script when having a command which just takes the full component list and does all the work at once is much much quicker...quicker then you will ever make it worrying about how long eval takes.
Actually then you have misunderstood the api a bit, its not entirely true that api yelds 1000*faster code, it might (but only sure to do thi if your way better coder than autodesk engineers). In fact you often get faster execution in mel than you get with API (as long as you ask the right commands). The problem here is that you don't have any way of asking closet distance in the api so you need to design the whole shebang from scratch wasting many days of code. Even api users call mel quite much. (im not beyond api development i do it every day after all, just knowing when to use what is what makes a master)
its about re usability.
People often thinks mel is evaled on fly IT isn't therefore eval does indeed carry a huge penalty. But the point is that is not any slower to write the code that does not eval. So using eval at all is a bit questionable, i mean its only a penalty you do for yourself on purpose. You could have spent the exact same time writing code that was faster.
you can easily demonstrate this:
CODE
proc doIt(){
for ($i=1;$i<1000;$i++){
string $eval="move -r ";
$eval+=(rand(10)+" ");
$eval+=(rand(10)+" ");
$eval+=(rand(10)+" ");
eval($eval);
}
}
CODE
proc doIt2(){
for ($i=1;$i<1000;$i++){
move -r (rand(10)) (rand(10)) (rand(10));
}
}
and:
CODE
proc doIt3(){
for ($i=1;$i<1000;$i++){
float $a=rand(10);
float $b=rand(10);
float $c=rand(10);
move -r $a $b $c;
}
}
PLEASE NOTE: i didnt optimize the code i would have written doIt2 becasue it would have been the shortest code to write so whet i would do is avoid un optimizing code like you do. And it enables me to write code faster. vbecasue the code is simpler
then if we time this with code with:
CODE
print("\tdoIt\tdoIt2\tdoIt3\n");
for($i=1;$i<10;$i++){
$di1 = `timerX`;
doIt;
$elaspedTime = `timerX -startTime $di1`;
$di2 = `timerX`;
doIt2;
$elaspedTime1 = `timerX -startTime $di2`;
$di3 = `timerX`;
doIt2;
$elaspedTime2 = `timerX -startTime $di3`;
print ("\t"+$elaspedTime+"\t"+$elaspedTime1+"\t"+$elaspedTime2+"\n");
}
youll see (do it 3 si sometimes afster than do it 2 on long run about equal, the subset here is too short):
CODE
doIt doIt2 doIt3
0.16 0.03 0.05
0.15 0.04 0.04
0.14 0.05 0.05
0.14 0.04 0.05
0.14 0.03 0.05
0.16 0.03 0.04
0.16 0.03 0.05
0.16 0.04 0.03
0.16 0.03 0.05
Now this is artificial but it just proves the point that eval is slow. it is as slow as having 3-4 times the code and its more tedious to write and read.
So now because mel is applied in a construction fashion NOT dg eval fashion, which si the job of api and factory nodes it does not matter since 0.04 is well within a persons click reaction time and 0.16 is starting to lag. But poit is thet theres no need to do this with the api as it would just take me many meny minutes for a benefit thats going to pay the extra time i set into it even millions of actions is still acceptably fast as i still only loose a half minute or so instead of 3. Now if you factor in how often its going to be used (again i don't use mel for dg time calc) , if it takes me 15 minutes to do the api equal and i gain 10 times the speed (i wont!) i would need to run this code 2000 times before i gain the lost time benefit. So if i run taht code every day 10 times thats one year form now. And te mel is much easier managed.
So this means the loops are perfectly viable many times especially when its no extra to write effective code.
Yes theres time to go api, just dont claim it dont matter Thing is you may want to quickly do code in future that reuses that code in a short maybe 100-1000 long loop and then it matters sightly.
CODE
The script doesn't assume that they are edge id's, it uses vertex id's;
yes thets right polySelect -shortestEdgePath wants vertex ids! my bad.
ps: one of the slowest operations in mel is to echo stuff, thus your right theres no benefit in this case but tahst jsut because flusing the print select makes it slower if you were to supress the script echo it would be much faster
As is refresh so changing time without refresh speeds code up by 1000 times. So baking a million keyframes does not take any time if you dont refresh viewports.
