ocamljsメモのバックアップ(No.7)

by keigoi

日本語の解説 &dagger;

max_int がおかしい(JSのintの範囲をこえる)ので closure compilerで圧縮できない
- 修正ずみ
string_of_float min_floatがSafari/webkitでおかしい
- Safariのバグ。最新のwebkitビルドでは直っている。min_floatは使わないこと
一部日本語文字列リテラルが化ける (未報告)
- src/jscomp/jsgen.ml を以下の通りコメントアウトしてみる
```
let utf8_encode s = s
(*  let len = String.length s in
  Utf8.from_int_array (Array.init len (fun i -> Char.code s.[i])) 0 len *)
```
- 日本語文字が"\u5E74"のようにエスケープされてしまうが、出力には影響ない
DateクラスのgetDayメソッド(曜日を取得)がない (未報告) http://jaked.github.com/ocamljs/doc/Javascript.date-c.html https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Date/getDay
getClientWidth?/getClientHeight?がない ← DOM標準ではないのでしょうがない？
document.stylesheet.insertRule ほか stylesheetクラスのメソッド

現時点のocamljsでは関数呼び出しのオーバーヘッドがかなりある
- 関数のカリー化や末尾呼び出しの最適化のため関数呼び出し1回につき2回の間接ジャンプがある(コールスタックが3倍に伸びる)
通常のPCでは全く問題ない。スマートフォンでもユーザとのインタラクションに影響があるほどではないが、数値計算などで扱うデータの量が多い場合には注意が必要（経験談）
生成されるJavaScript?は元のOCamlコードの原型が残っているので、Google Closure Compilerによる圧縮と併せて理想的なJavaScript?に落ちるようなOCamlの書き方を探すこともできる
- 特にモジュールをまたいだ呼び出しが最適化されないためListやArrayモジュールのほとんどが低速。効率化するならばまずmap/fold系の高階関数をやめfor式を使い、配列のアクセスを Array.unsafe_get / unsafe_set に置き換えるか、 a.(i)記法を使うならばoc$arefの境界チェックを外してclosure compilerで最適化する。
- このような最適化をプロファイルの後にごく一部で行うだけで劇的に改善できる。どうしても駄目なときはインラインJavaScript? << ... >> を使う。型がないので注意

以前はclosure compilerでSIMPLE_OPTIMIZATIONすると動かなかった(keigoiの日記参照)が修正された。
closure compilerでADVANCED_OPTIMIZATIONすると動かないが、出現する m.$oc などを m['$oc'] に置き換えれば動くようになる。 (未報告)
- ADVANCED_OPTIMIZATIONはいくらかdead code eliminationや簡単なインライン化もやってくれるので有用。
- ADVANCED_OPTIMIZATIONでは o.field 形式のフィールドアクセスにおけるフィールド名が全て o.a のように短縮されてしまうが、 o['field'] のように文字列にすれば短縮されない。詳しくはclosure compilerのページ参照