filePathを調べる

filePathを調べるための大まかな処理内容は

1. ファイルコマンドでシーン名をクエリー。
2. その文字列をスラッシュで分割。
3. ファイル名の一つ前まで繋げる。

みたいな感じでしょうか。
で、ＭＥＬにすると２つの書き方ができます。

まず、文字列の分割にstringToStringArrayコマンドを使う場合

{
    string $file=`file -q -sn`;
    
    string $temp[]=stringToStringArray( $file,"/" );
    
    string $path;
    for( $i=0; $i<(`size $temp`-1); $i++ ) $path+=($temp[$i]+"/");
    
    print("\n$path: "+$path+"\n");
    
}

そして、文字列の分割にtokenizeコマンドを使う場合

{
    string $file=`file -q -sn`;
    
    string $temp[];
    int $token=tokenize( $file,"/",$temp );
    
    string $path;
    for( $i=0; $i<($token-1); $i++ ) $path+=($temp[$i]+"/");
    
    print("\n$path: "+$path+"\n");
    
}

で、引っかかった部分は、stringToStringArrayコマンドを使った場合の、for 内の(`size $temp`-1)
JavaScriptなんかでは、パフォーマンス改善のテクニックで.lengthみたいなプロパティ参照を使わず.lengthを変数に代入した方がコストが下がるとかあったりしますが、sizeコマンドのコストはどのくらいなのだろうか？
ということです。
ま、コスト的に微々たる物なんでしょうけども・・・。
なんか気持ち悪い。
melのプロファイラなんかで見るとsizeコマンドの参照数が真っ赤になりそうではあるけれども。

そんなかんじで、forの中から(`size $temp`-1)を抜き出すと

    string $temp[]=stringToStringArray( $file,"/" );
    int $back=(`size $temp`-1);
    
    string $path;
    for( $i=0; $i<$back; $i++ ) $path+=($temp[$i]+"/");

みたいにtokenizeと変わらない、逆にタイピング数多くなっていると言うね。

気にしない人は気にしないようなどうでも良い話でした。