気軽に手軽に定義できるけれど、決してパフォーマンス良くないんですよね。パフォーマンス改善」について少し解説してみます。良い例がなかなか浮かばなかったのですが、単純すぎず複雑すぎずと言うことで、Xorshift(32bit版)を取り上げます2。シンプルに実装してみます。いう関数外(静的スコープ内)の変数を参照・更新しながら、次々と次の値を算出しています。マクロの結果を見る限りは、別にそんなにパフォーマンス悪くなくね?て思われるかもしれません。部分が赤(系の警告色)で表示されています4。これが何を意味しているのかというと。型として扱っちゃいますよ」という事態が起こっているのです。型のはずなのに、JITコンパイラ(正確にはその手前の型推論時の最適化処理時)にはそれが分からないのです。型としか扱えないですよ」ということ。早い話が、最適化が全く期待できないのです。いう中間コードが現れています。)』みたいな感じになっています。これ、なんだかもったいなさそうですよね。入れ子になって2ステップ踏んでる。これ減らせると、パフォーマンス改善に繋がりそうですよね。この2点を解決・解消する、2つの方法を紹介します。適当な箇所に型アノテーションを付けたりして、以下のように書き換えてみました。用意し基本そちらで処理。KiB)実行結果は期待通り。結果も見てみましょう。コードの最初の方に2箇所、最後に1箇所の、計3箇所に減りました。一方で、変換後のコード自体はむしろごちゃごちゃした印象を受けるかもしれません。各演算子が適切な関数に置き換えられたコードが表示されているのです。方は、最適化処理が走っていないために、プログラマが記述したコードほぼそのまま直訳したモノになってしまっているわけです。いう形で書き直してみます。変更可能な型の定義5。ように『(対象となるインスタンスとその)型』を記述した形になっています6。簡単に言うと、「呼び出し可能オブジェクト」のことです。ように、関数呼び出しの書式で特定の処理を実行できるオブジェクトのこと。