2

我正在 ClojureScript 应用程序中处理大型 JSON 文件（基本上包含树状结构）。基本上，我遍历了该树结构中的所有元素，这些都是相当多的操作。现在我想知道 Lazy Hash map 处理会导致多少开销。

基本上我：

  • 通过 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访问器语法和谷歌闭包 foreach 函数来重写那个特定的源代码。你怎么看？

我已经在类似的优化主题上看到了提高 ClojureScript 程序的性能，我认为这也意味着这loop .. recur似乎是一个可行的循环选项。那正确吗？

4

1 回答 1

2

If it is under your control, consider producing EDN instead of JSON on the server side. I'm not sure if parsing a EDN string is faster than converting JSON to EDN, but at the very least it will reduce your app's complexity to some degree.

As per your description, it sounds like the data structure will be "read-only". Then the object construction cost is practically the only one you have to consider - reading it later will be cheap (persistent maps and vectors have near-constant access time).

Depending on the data structure size, the user might or not might not perceive how the UI blocks due to this computational task at page-load time. Consider measuring it.

Between that JS arrays can be treated as seqs, and that keyword keys are not as powerful in ClojureScript as they are in Clojure (here they do not implement IFn), there actually aren't that many advantages of EDN over JSON in this particular case.

As for iteration, while maps/vectors aren't lazy, the results of Clojure(Script)'s data processing functions (map/filter/etc) do return lazy sequences - and generate intermediate collections in the way.

You can avoid the associated overhead by using the recently-ported reducers library, and the transient/persistent! facilities (if this turned out to be an actual issue in your app).

于 2013-05-28T06:38:19.097 回答