JavaScript をわずかでも速くするために | WordPressのカスタマイズ

Contents

• if-else or switch
• ループ は何を使うべきか
• DOM の更新
• ビット 演算子

« if-else or switch »

if-else 文においては、可能性の高いものから条件を並べること。なるべく通過する条件式の数を少なくした方が速くなるというのは、当然の事のように思える。可能性的に均等で条件式の数が多い場合は、工夫して入れ子にし、なるべく通る条件式の数をへらすようにする。 そして、実は if-else よりも switch の方がより高速で、それは条件式が増えるほどに顕著になるということ。これは知らなかった。この本は随分と前に買ったものだけれど、その当時は高速化ということにまで、まだあまり気がまわらなかったのだと思う。
この本自体がもうだいぶ前に出版されたものなので、はたして現在のブラウザにおいても当てはまるものなのか、ちょっと試してみる必要がありそうだ。

比較するのは、if-else 、switch、そして自分としては php 同様にこれがもっとも高速なのだろうと信じ切っていた配列によるルックアップテーブル。配列（オブジェクト）によるルックアップテーブルは、評価する値が条件に完全に含まれている場合とそうでない場合（含まれるかどうかで if 条件文が必要になる）、また値が数値か文字列かでもかなり違いがあるだろうと思われる。if-else、switch においては条件の数を一つへらしてその分を、else、default で補う。これで、if-else、switch においては、評価する値が条件の中に必ずしもあろうとなかろうと関係の無いことになる。

と、いうことで下のコード。
時間を計測する measure 関数は、ネットか本かどこからかいただいてきたものだと思う。忘れてしまった。
基本的には下の感じで、あとは条件を増やしたり、評価値を含まれないようにしたりとか、文字列を数値に変えたりとかで実験した。これで良いと思うのだけれども。swconb というのは、数値で評価する場合に、数値の大小で評価させるもの。これでも違いがあるはず。
見ての通り、それぞれ各100,000回まわして、その結果を10回づつとり平均を出した。

// 関数の実行時間を計測する関数
// 実行にかかった時間をミリ秒で出力
function measure( name, func ) {
	const start = performance.now();
    func();
    const end = performance.now();
    
    const elapsed = ( end - start );
    const elapsedStr = elapsed.toPrecision(3);
    console.log( `${name}: ${elapsedStr}` );
}

// 評価値：文字列　条件：3ケ 配列ルックアップテーブル：評価値は条件に必ず存在
const 	roop = 100000,
	mathobj = { a: 1, b: 2, c: 3 },
	keyary = [ 'a', 'b', 'c' ];

function ary( keyary, mathobj, roop ) {// array look-up-table
	let ans = 0;

	for ( let i = 0; i < roop; i++ ) {
		const rand = Math.floor( Math.random() * 10000 ) % keyary.length,
			tarstr = keyary[ rand ];

		// if ( mathobj[ tarstr ] ) {
			ans += i + mathobj[ tarstr ];
		// }	
	}
}

function ifcon( keyary, roop ) {// if-else construct
	let ans = 0;

	for ( let i = 0; i < roop; i++ ) {
		const rand = Math.floor( Math.random() * 10000 ) % keyary.length,
			tarstr = keyary[ rand ];

		if ( 'a' === tarstr ) {
			ans += i + 1;
		} else if ( 'b' === tarstr ) {
			ans +=  i + 2;
		} else {
			ans += i + 3;
		}
	}
}

function swcon( keyary, roop ) {// switch construct
	let ans = 0;

	for ( let i = 0; i < roop; i++ ) {
		const rand = Math.floor( Math.random() * 10000 ) % keyary.length,
			tarstr = keyary[ rand ];

		switch ( tarstr ) {
			case 'a':
				ans += i + 1;
				break;
			case 'b':
				ans +=  i + 2;
				break;
			default :
				ans += i + 3;
		}
	}
}

function swconb( keyary, roop ) {
	let ans = 0;

	for ( let i = 0; i < roop; i++ ) {
		const rand = Math.floor( Math.random() * 10000 ) % keyary.length;

		switch ( rand ) {
			case rand < 1:
				ans += i + 1;
				break;
			case rand < 2:
				ans +=  i + 2;
				break;
			default :
				ans += i + 3;

		}
	}
}
	
measure( 'ary', () => { ary( keyary, mathobj, roop ); } );
measure( 'if', () => { ifcon( keyary, roop ); } );
measure( 'swtch', () => { swcon( keyary, roop ); } );
measure( 'swichb', () => { swconb( keyary, roop ); } );

下の表で表題の文字列というのは、評価値が文字列。数字は条件の数。”含”は配列のルックアップテーブルの要素に、評価値を必ず持っているということ。”不”の場合は、評価値が存在しない場合もあり、その条件式が必要になるということ。単位はms 。

測定環境：
Windows10 Core i5-6500 Apache24
FireFox Developer Edition 87.0b5
Google Chrome 88.0.4324.190

こうしてみると、条件判断においては FireFox の方が若干ながら高速なよう。評価値が文字列の場合、ルックアップテーブルは連想配列を使うことになり、その場合は if-else、switch 構文よりも遅くなってしまう。が、いざ、評価値に数字を使えるならばただの配列ですみ、この場合は文句なく最速となる。if-else、switch においては、ほんとにわずかながら（ 10万回まわしてミリ秒でこれだけしか違わないのだから ）switch のほうが速いようだけど、どちらを使っても、という感じがする。特に何もないのであれば、なるべく switch を使うようにして、あとは書きやすさとか読みやすさで選択すればいいのだろうと。
ただ、評価値に数字を使える状況ならば、配列のルックアップテーブルを使うということだと。特に条件の数が多くなればなるほど、その差は大きくなるのだと思われる。

• まとめ：
• 評価値が数値ならば、配列のルックアップテーブルを使う。
• 評価値が文字列ならば、switch を使うようにする。

« ループ は何を使うべきか »

php はシンプルでいいのだけれど、JavaScript の場合は for、foreach、for-of、for-in などなどある。map もあるけれど、ちょっと用途が違うかと思うし、あまり速そうでもないのでこの場合はパス。いろいろあってもその時々のやりたいことで選べばよいのだろうけれど、はたして for だけで全てがまかなえるといえばそうでもありそうだし（ for-in は？）。簡単に書けるものが、速さも同等であれば喜ばしいことなんだけれど。
と、いうことで色々並べてやってみようというところ。

const baseobj = { a: 'id', b: 'sortid', c: 'area', d: 'name', e: 'grade', f: 'charge', g: 'term', h: 'note', i: 'url', j: 'pr', k: 'targetid', l: 'ipadrs', m: 'token', n: 'ope' },
	baseary = [ 'id', 'sortid', 'area', 'name', 'grade', 'charge', 'term', 'note', 'url', 'pr', 'targetid', 'ipadrs', 'token', 'ope' ],
	roop = 100000;

function objfor( baseobj, roop ) {// objfor
	const tar = baseobj,
		tarkey = Object.keys( tar ),
		tar_len = tarkey.length;

	let tmp = '';

	for ( let i = 0; i < roop; i++ ) {
		for ( let j =0; j < tar_len; j++ ) {
			tmp = tar[ tarkey[ j ] ];
		}
	}
}

function objent( baseobj, roop ) {// obj entries
	const tar = baseobj;

	let tmp = '';

	for ( let i = 0; i < roop; i++ ) {
		for ( const [ key, val ] of Object.entries( tar ) ) {
			tmp = val;
		}
	}
}

function objfof( baseobj, roop ) {// obj for-of out
	const tar = baseobj,
		tarkey = Object.keys( tar );

	let tmp = 0;

	for ( let i = 0; i < roop; i++ ) {
		for ( let j of tarkey ) {// for-of で得られるのは値の方
			tmp = tar[ j ];
		}
	}
}

// こちらが for-of + Object.keys を使う時のよく紹介されている書き方
function objfofo( baseobj, roop ) {// obj for-of
	const tar = baseobj;

	let tmp = '';

	for ( let i = 0; i < roop; i++ ) {
		for ( let j of Object.keys( tar ) ) {
			tmp = tar[ j ];
		}
	}
}

function objfin( baseobj, roop ) {// obj for-in 
	const tar = baseobj;

	let tmp = 0;

	for ( let i = 0; i < roop; i++ ) {
		for ( let j in tar ) {// for-in で得られるのはキー(プロバティ)の方
			tmp = tar[ j ];
		}
	}
}

function objfinh( baseobj, roop ) {// obj for-in has
	const tar = baseobj;

	let tmp = '';

	for ( let i = 0; i < roop; i++ ) {
		for ( let j in tar ) {
			if ( tar.hasOwnProperty( j ) ) {
				tmp = tar[ j ];
			}
		}
	}
}

function objfoe( baseobj, roop ) {// obj foreach
	const tar = baseobj;

	let tmp = 0

	for ( let i = 0; i < roop; i++ ) {
		Object.keys( tar ).forEach( function ( k ) {
			tmp = tar[ k ];
		});
	}
}

function aryfor( baseary, roop ) {// ary for
	const tar = baseary,
		tar_len = tar.length;

	let tmp = '';

	for ( let i = 0; i < roop; i++ ) {
		for ( let j =0; j < tar_len; j++ ) {
			tmp = tar[ j ];
		}
	}
}

function aryfof( baseary, roop ) {// ary for-of
	const tar = baseary;

	let tmp = '';

	for ( let i = 0; i < roop; i++ ) {
		for ( let j of tar ) {
			tmp = j;
		}
	}
}

function aryfin( baseary, roop ) {// ary for-in
	const tar = baseary;

	let tmp = '';

	for ( let i = 0; i < roop; i++ ) {
		for ( let j in tar ) {
			tmp = tar[ j ];
		}
	}
}

function aryfoe( baseary, roop ) {// ary foreach
	const tar = baseary;

	let tmp = '';

	for ( let i = 0; i < roop; i++ ) {
		tar.forEach( function( v, i, a ) {
			tmp = v;
		});
	}
}

measure( 'objfor', () => { objfor( baseobj, roop ); } );
measure( 'objent', () => { objent( baseobj, roop ); } );
measure( 'objfof', () => { objfof( baseobj, roop ); } );
measure( 'objfofo', () => { objfofo( baseobj, roop ); } );
measure( 'objfin', () => { objfin( baseobj, roop ); } );
measure( 'objfinh', () => { objfinh( baseobj, roop ); } );
measure( 'objfoe', () => { objfoe( baseobj, roop ); } );
measure( 'aryfor', () => { aryfor( baseary, roop ); } );
measure( 'aryfof', () => { aryfof( baseary, roop ); } );
measure( 'aryfin', () => { aryfin( baseary, roop ); } );
measure( 'aryfoe', () => { aryfoe( baseary, roop ); } );

これも10万回まわしたのをそれぞれ10回づつ結果をえて、その平均の値。( ms )

この結果をみると、条件文の場合とは異なり、ループに関しては圧倒的に Chrome の方が高速らしいということ。特にオブジェクトにおける for-in の速さは圧倒的で使いたくなってしまうほど。hasOwnProperty の条件式をつけてもほとんど変わらないパフォーマンス。そして、「 O'REILLY High Performance JavaScript 」にはこういう注意書きがある。
「 for-in を使って配列の要素を反復処理することは絶対にやめるべきである。 」と。確かに配列においての for-in のパフォーマンスをみると極端に悪くなっている。まぁ、もともと違う用途のためにあるものだし、いらぬものまで入ってきてしまうからなのであろうけれど、オブジェクトに対してであれば、ということなのだろう。この本にも、for-in ループは際立って遅く、その他のループに関してはほぼ同様のパフォーマンスを示すと書いてある。ブラウザの進歩とともに状況は大きく変わってきているようではあるが。なんにしても for-in を使うにしろ、FireFox での hasOwnProperty を使用した時のパフォーマンスの悪さが気になるところではある。
Object.keys + for-of の組み合わせでネットなどでよく紹介されているのは、for の （）の中にObject.keys を入れている書き方。一文ですむのでかっこはいいかもしれない。けれど、これを見てもしや！と思い外に出してみると、案の定、いくらか速くなった。みてくれをとるか実用性をとるかってところ。

連想配列（オブジェクト）でも Object.keys でキーの配列をとってそれをループさせれば、単純な配列のループと大差ないのでは？と思っていたのだけれど、結果は大違い。連想配列にアクセスすること自体が処理を重くさせるのかも。であれば、なるべく連想配列の使用を避けたくなる。それでも連想配列をループさせる必要がある時で、必要なものが値の方だけであるなら、Object.values で値だけの配列をつくってループさせたほうが、速度的には有利なはず。キーが必要なら Object.keys も使って・・・、となるけれど Object.keys の方はキーの並びの順番に関しては保証されないので、数字などキーの値によってはソートされてしまい、元の連想配列との整合性がなくなってしまうから使えない。
まぁ、この結果を見る限り、現状においては、使いなれた for がやはりという感じがするので、連想配列をループさせる場合は、わずかにでも速く！ということなら、ちょっとばかり工夫が必要ということになるか。

あと、ちょ～基本的なことではあるけれど、あれっ！どっちだっけ？となるのが、for-of で得られるのは値の方で、一方の for-in はキー（ プロパティ ）の方だってこと。

• まとめ：
• ループに限ったことではなく、極力オブジェクト（連想配列）の使用を避ける
• 連想配列をループする必要がある時は、hasOwnProperty の条件文がいらないことが保証されるときは for-in。でなければ Object.keys を取得して それを for でループさせる。そのループで必要なのが値だけならば、Object.values で値だけの配列を取得してそれを for にてループ。
  その後、時が経ち Firefox が v99 となり、hasOwnProperty の条件式をつけても chrome 同等のパフォーマンスを示してくれるようになった。ゆえに、連想配列をループする場合は、迷わず hasOwnProperty の条件式付きでの for-in を使う。おもしろいことに hasOwnProperty の条件式を付けたほうが、Firefox、Chrome 双方ともに速いのである。
• 配列のループは昔ながらの基本、 for の一択

« DOM の更新 »

JavaScript からスタイル設定を変更する場合、それが複数ある場合に、それぞれ一つづつを変更していくのではなく、style.cssText によってまとめて処理をした方が再描画と再配置の回数を減らすことができてパフォーマンス的に有効だとのこと。まぁ、これも感覚的にわかっているようなことではある。
ここで一つ注意しなければならないのは、cssText によってスタイル設定を変更した場合、インラインでスタイル設定してある部分は、上書きされてしまいまっさらになってしまうということ。
インラインでのスタイル設定というと、HTML のタグのなかに直に、style="font-size:1.0em" のようにして書いてあるもののことで、スタイルシートや <head> タグ内に、<style> タグを使って書いてあるものではないということ。よって、スタイルシートや <style> タグで設定してある部分は、cssText によって設定されていないものがなくなってしまったりはしない。はずなんだが・・・。逆に、以前に cssText を使って設定したスタイルは見事に無くなってしまう。
新たに、cssText によって設定する場合、以前に設定した部分を引き続き残しておきたい場合は、+= を使って設定してやれば良い。同じ対象に対して += で何度も設定しても、更新されていくだけで重複してたまってしまうことはない。

document.getElementById( 'maincontent' ).style.cssText += 'opacity:0;visibility:visible;background:url(./wp-content/themes/first/flying_ss.png) no-repeat 0 0';

一文で設定できるのは、書く方としても助かるのでありがたいのだけれども、今回、ちょっと気になる点もあった。それは Chrome においてのこと。前述したように version は 88.0。アニメーション用に複数の画像を一つにしてbackground として設定し、背景画像の位置を変えることでアニメーションさせていた。アニメーションさせるとともにその要素自体の位置も移動させていたのであるが、これが画像が変わるたびにチラチラと光るようなノイズが出てしまう。FireFox ではそんなことはおこらず、 Chrome であっても cssText を使わず、一つ一つスタイル設定を更新させていけばそんな状況にはならなかった。なにかやり方というか、こつみたいなものがあるのだろうか。

と、いいつつも実はこの件に関しての原因というのは実にシンプルなもので、Chrome の場合、 ディベロッパーツールを表示させていると起こる現象であって、それを閉じていればチラチラノイズが出ることはなかった。まぁ、ディベロッパーツールが相当に負荷が多くなっているということなんだろうけれど。でも、この件において少し気になったこともあるので、今ひとつ、すっきりしない部分ではあるのだけれど・・・。

この件についての続きはこのページにて・・・＞ 「いまさらの Javascript style.cssText」

« ビット 演算子 »

これまでほとんど接したことのないビット演算。ただ、このビット演算、JavaScript でもその他の数値演算やブール演算子と比べて信じられないほどの高速とのことらしいが。いやはやなんとも・・・。
とにかくわずかでも高速化させたいのであれば・・・、ということで、ならば試してみるしかない。
ビットというと二進法のただ 0 と 1 だけの世界、01010100111 のようなデジタルな世界でなんともわかりづらそうな雰囲気なのではあるけれど、ここでちょっとだけ使うのはもっとわかりやすい単純なものだけ。

ループをさせて、そのなかで交互に処理を変えるなんてのはよくあること。そのとき、２で割った余りの 0 か 1 で条件分岐させるなんてのは常套手段。で、まずはここでビット演算が使えるということ。これも「 O'REILLY High Performance JavaScript 」で教わったことになる。
この場合、必要なのは ビット AND。演算子は &。
これは、対応するビットが両方とも 1 だった場合に 1 を返す。で、2 で割った余りの 0 か 1 かで条件分岐をビット演算ではどう置き換えるのかということを先に下にしめすと・・・、

for ( let i = 0; i < n; i++ ) {
	if ( i % 2 ) {
		console.log( 'Yes true' );
	}

	if ( i & 1 ) {// i が偶数のとき0、奇数のとき1 となる
		console.log( 'Yes true' );
	}
}

６行目。実にシンプル。ただ 1 との ビットAND をさせるだけ。 1 は二進法でも 1。で、二進法では偶数の1桁目（ 1桁目？でいいのか？なんていうのか？1の位？ ）は必ず 0。奇数なら必ず 1。これはパソコンの電卓を出してちょっと数字を打ってみればすぐに確認できる。ということで 1 とビットAND をさせれば偶数のときは 0 だし奇数のときは 1 となる、という極めてわかりやすくシンプルなことでそれを利用すべきってことだろうけれど。もともと計算自体が超高速なことだから、これを一つ箇所変えたからと言って体感的にはまったく変わらない。まぁ、すでにあるものをわざわざ変更してなんてものではまったくない。新しく書く場合には、知っていて損はないかもね！という感じのものだと。でも、ビット演算を知っている人には一目瞭然なんだけれど、知らない人にはなんのことかさっぱりだろうからそのあたりも・・・。
これのちょっとした応用としては、たとえば選択子が８個あってそれからランダムに一つ選び出すとか。これも８で割った余りにすれば良いのだけれど、その数が８のような２の累乗であればビット演算が使える。この場合、８より一つ小さいというか８で割った余りの最大値である７でビットANDさせればいい。ある数でビットANDを行うとその数より大きな数字は返ってこない。それが７なら８以上の数は返ってこない。ならばなぜ７なのかというと、それは２の累乗数から１引いた数の２進数をみるとすぐにわかる。1->1、3->0011、7->0111、15->1111、31->00011111、63->00111111、・・・、という具合に 0 と 1 がきれいに並ぶ。ビットAND をさせた場合、こちらが 0 の桁は相手がなんであろうと（ って 0 か 1 しかないのだけれど ）全く関係なし。こちらで 1 が並んだ桁数だけが有効になるので、こちらが全て 1 ということは、その有効な桁数だけにおいて相手の完全なコピーになるということ。こちらの有効な桁数の中に 0 を含んでいたとすると、相手が 1 でも 0 になってしまうので、結果で得られた数字に偏りが生じてしまう。と、いうことで有効な桁数で全て 1 が並んでいるということが必要になっている。
なんだけれども、実際にベンチで計測してみたところ、普通に割って余りを求めたものとほとんど変わらなかった。というか、余りを求めた方が速いときすらよくあった。ので、現在ではこういうことでビット演算を使う理由もあまりないのかもしれない。ちなみに、php ではどうだろうかと思い、 8 で割った余りで同じく10万回回して試してみたところ、ビット演算のほうが速い結果が出た。もともと超高速なただの計算なので、その差は僅かなものではあるけど。それも続けて計測させると、二度目、三度目の計測ではどんどん差はなくなっていく。まぁ、そんなに感じられるほどの差はないということで、それでもこういう小さなことが積もり積もって影響がでてくるのだろうか。
ということで、この件はこれにておわり。