FujisakiJavaScriptでパフォーマンスを出すことを...強いられるんだ!!!(カッで、今回はその関係で色々試したことの一つについて、昔やった結果を纏めたのを書きました。TypedArray最近のJavaScriptにはTypedArrayというのがあります。通常のJavaScriptの配列は、要素にどんな型でも入れられる上、厳密には配列ではなくハッシュであるため効率が悪いのですが、このTypedArrayでは配列の型を指定した本物の配列であるため、高速・効率的に処理できます。JSでOpenGLを使うWebGLという技術向けに策定された仕様なのですが、別にWebGLでなくても使用できて、以前開発したJSのファミコンエミュレータでも、ファミコンのRAMやフレームバッファをこれで表現しています。このTypedArray、色々とメソッドが定義されていて、よく使う処理は大体網羅されているのですが、memset(メモリ全体を特定のデータで塗りつぶす)を行うようなメソッドがありません。使う処理だと思うのですが、無いのでなんとかJSで塗りつぶさないといけない、という事になります。今回はTypedArrayのmemset処理について色々と試してみた結果を書きます。}}));一番遅そうですが、一番オーソドックスな方法です。4957msになりました。いうことで、5000ms前後がベースラインということになります。これから遅くなったらむしろ逆効果ということでです。方法2:小さい配列をループで初期化してsetで回すsetというメソッドがあって、これを使うと複数の要素を一気に上書きすることができます。100バイト目から1,024バイトがanother_memの内容に上書きされるさらにこのanother_memの作り方として、上のようにnewで作る方法とsubarrayを使って元の配列を部分的に共有したものを使う方法があります。全部ネイティブで0にするより、一旦小さな配列を0で埋めてからsetでセットしたほうが速い気がしませんか。全部JSのループで回すのは遅いというのがわかりましたし、かといってあんまり小さな配列を使って何度もsetを呼び出してもネイティブ呼び出しのオーバーヘッドが重いだろうと思われるので、このバランスをどうするかが問題になります。今回は、1KBから1MB(意味なし)まで変化させて測定しました。Uint8Arrayで配列を作ってコピーする方法subarrayを使って小さな配列を作る方法やっぱり小さな配列を作ったほうが速いと、いうわけで、8192くらいの配列を作ってsetで回したほうが大体17倍くらい速いです。subarrayの方が配列生成コストが変わってくるのかなぁ、と思ったのですが、あんまり変わらないようですね。Bridge)というひっっっっっっじょうに限られた環境での値なので、あんまり鵜呑みにしないほうがいいと思います。JSの実行速度がネイティブ関数呼び出しのコストに対して相対的に速い環境があればこの値は大きくなるかもしれませんし、ネイティブ関数呼び出しのコストがJS実行速度よりも相対的に安い環境があれば、この値は小さくなってくると予想されます。結論HTML5のTypedArrayでは、メモリの内容を特定の値で塗りつぶすとき、subarrayでも新しくつくるのでも、他のTypedArrayを用意してそれを特定の値で塗りつぶしてからsetを繰り返す方がとても速い8192bytesの配列を用意すると一番速かったけど、他の環境では分からない。ターゲットの環境で調べれば良いのでは(クロスプラットフォームを無視した言い方)JSは大変ですね...。Fujisakiこんにちは。最近なぜかFedora17が動かなくなった(えっ)ので、Fedora18にアップデートしました。Control_LFedora18にアップデートしたところ、うまく動かなくなってしまいました。それを今回対策したので、メモっておきます。~/.Xmodmapって入力して実行すると今までどおりちゃんと設定が反映されるようになってるはずです。いうわけで、これを自動で実行するようにしましょう。gnome-session-propertiesを起動するコンソールからgnome-session-propertiesを実行します。${YOUR_HOME}/.Xmodmapと入力してSaveして、再ログインすれば反映されるはずです。ここで重要なのが、xmodmapを絶対パスで指定しておくことです。PATH変数がうまく設定されてないのか、xmodmapとだけ書いても動きません。agentはここで実行されている他のエントリを見てみると中々面白いです。agentとかどこで実行されてるのか割と不思議だったのですが、この中だったのですね。Linux版Dropboxのクライアントなどもここで実行されています。FujisakiC++のテストフレームワークのGoogleTest、活用してますか!!私は大好きです!!(何テストフレームワークを使ってると、マクロを使って似たようなテストをまとめたくなる時があると思います。前後のセットアップだけ同じで型名とテストする値だけが違うとか。できればテンプレートを使ったほうがいいと思いますが、そうもできない場合もあるでしょう。0x8000);...}でも、コレは動かないのです。こんなエラーメッセージが出ちゃいます。‘gtest_label_testnothrow_720’さて...GOTOのラベルがかぶっているようです。なんでなのかは、ASSERT_NO_THROWの先を見ればわかります。throws.")というわけで、GOTOのラベルに__LINE__マクロで取得した行数を使っているのですが、関数風マクロで展開するソースは一行で展開されるので、先ほどの_MY_TESTの複数のASSERT_NO_THROWで同じ__LINE__が使われてしまい、GOTOのラベルがかぶるのでさっきのようなエラーでコンパイルエラーになってしまったのでした。