2

ClojureScript アプリで大きな JSON ファイル (基本的にツリーのような構造を含む) を操作しています。基本的に、私はそのツリー構造のすべての要素を反復処理しますが、これらはかなりの数の操作です。ここで、Lazy Hash マップの処理によってどれだけのオーバーヘッドが発生するのだろうかと考えています。

基本的に私は：

  • AJAX 経由で JSON ファイルをロードする
  • ブラウザを使用してJSオブジェクトに変換しますJSON.parse
  • js->clj :keywordize-keys trueそれをclojure構造に変換するために使用します

JSON の構造は、ネストされたリストとハッシュ マップで構成されます。何かのようなもの

{:A-key-a [{:B-key-a 34  :B-key-b [213. 23.4]}
                   {:B-key-a 34  :B-key-b [213. 23.4]}
                   ...] 
 :A-key-b [{:someother-a 30 ...}
                   ...]
 ...}

ここで、速度を上げるために JS オブジェクトを直接使用するようにフォールバックする必要があるかどうか疑問に思います。直感的には、これは ClojureScript オブジェクトよりも高速であると思いますが、時期尚早に最適化したくないし、遅延評価によって導入されるオーバーヘッドを判断するために ClojureScript の内部について十分に知りません。

.-mykeyその特定のソースコードを書き直すために、アクセサー構文とGoogleクロージャーforeach関数を使用できると思います。どう思いますか？

同様の最適化トピックでClojureScript プログラムのパフォーマンスを改善するを見たことがありますが、これloop .. recurはループの実行可能なオプションであるように思われることも意味していると思います。そうですか？

4

1 に答える 1

2

管理下にある場合は、サーバー側で JSON ではなく EDN を生成することを検討してください。EDN 文字列の解析が JSON を EDN に変換するより速いかどうかはわかりませんが、少なくともアプリの複雑さがある程度軽減されます。

あなたの説明によると、データ構造は「読み取り専用」になるようです。次に、実際に考慮しなければならないのはオブジェクトの構築コストだけです。後でそれを読むと安くなります (永続的なマップとベクトルのアクセス時間はほぼ一定です)。

データ構造のサイズに応じて、ユーザーは、ページの読み込み時にこの計算タスクが原因で UI がどのようにブロックされるかを認識する場合と認識しない場合があります。それを測定することを検討してください。

JS 配列は seq として扱うことができ、ClojureScript のキーワード キーは Clojure ほど強力ではありません (ここでは を実装していませんIFn)。実際、この特定のケースでは、JSON よりも EDN の方がそれほど多くの利点はありません。

反復に関しては、maps/vectors は遅延ではありませんが、Clojure(Script) のデータ処理関数 (map/filter/etc) の結果は遅延シーケンスを返し、途中で中間コレクションを生成します。

最近移植されたレデューサーライブラリとtransient/persistent!機能を使用することで、関連するオーバーヘッドを回避できます (これがアプリで実際の問題であることが判明した場合)。

于 2013-05-28T06:38:19.097 に答える