実行効率の最適化を試みた

これまで、Xtalの仮想マシンはバイトコードで動いていました。
マシンがもっとも早く読み書きできるサイズの整数を使うワードコードとどっちにしようか迷ったのですが、メモリの節約とエンディアンの違いを考慮しなくてもいいという理由から、バイトコードで作りました。

しかし、やっぱ速度の方が大切だ！と思い、マクロでバイトコードマシン<->ワードコードマシンを切り替えられるように修正しました。めっちゃ大変でした。

無事、どちらでもちゃんと動くようになり、速度を計測したところ、なんと！

6.8秒で動いてたスクリプトが、6.6秒で動くように！その差3%！

ワードコードマシンだめだ…

続 最適化

そもそもインスタンス変数へのアクセスが遅すぎるような気がしてきました。

いろいろ調べた結果、VC2005付属のSTLのvector::operatorが遅いんじゃないかという結論に達しました。

vector::operatorは次のようになっています。

	reference operator[](size_type _Pos)
		{	// subscript mutable sequence

 #if _HAS_ITERATOR_DEBUGGING
		if (size() <= _Pos)
			{
			_DEBUG_ERROR("vector subscript out of range");
			_SCL_SECURE_OUT_OF_RANGE;
			}
 #endif /* _HAS_ITERATOR_DEBUGGING */
		_SCL_SECURE_VALIDATE_RANGE(_Pos < size());

		return (*(_Myfirst + _Pos));
		}

_HAS_ITERATOR_DEBUGGINGは _DEBUGが定義されているときだけ定義されるようです。Release時には関係ありません。

下の、_SCL_SECURE_VALIDATE_RANGEは_SECURE_SCLが0以外のときに定義されるようです。
_SECURE_SCLは

#if !defined (_SECURE_SCL)
#define _SECURE_SCL 1
#endif

とあり、_SECURE_SCLが定義されてなければ1として定義されるようです。つまり、明示的に_SECURE_SCL=0と定義しないとRelease時にも定義されてしまうようです。
実際_SECURE_SCL=0とプリプロセッサ定義してあげると、6.8秒かかっていた先日のインスタンス変数アクセスベンチマークプログラムは3.9秒で動くようになりました。

みなさんコレ(_SECURE_SCL)どうしてるんですか？