この記事を書いた後、私はお金を口に出すことに決め、私の以前のプロジェクトを使用するように変換し始めましたrecursion-schemes。
問題のデータ構造は遅延 kdtreeです。明示的および暗黙的な再帰の実装を見てください。
これは、主に次の行に沿った単純な変換です。
data KDTree v a = Node a (Node v a) (Node v a) | Leaf v a
に
data KDTreeF v a f = NodeF a f f | Leaf v a
シバン全体のベンチマークを行ったところ、このバージョンは通常のバージョンよりも約 2 倍遅いことがわかりました (実行KDTreeF全体をここで見つけてください)。
Fixここで私を遅くしているのは、追加のラッパーだけですか? そして、これに対して私にできることはありますか？
警告:
- 現時点では、これは (V3 Double) に特化しています。
- これは、アナモフィズム アプリケーションのカタ - アフターです。ハイロモーフィズムは kdtree には適していません。
cata (fmap foo algebra)数回使用しています。これは良い習慣ですか？- エドワーズ
recursion-schemesパッケージを使用しています。
編集1：
これは関連していますか？https://ghc.haskell.org/trac/ghc/wiki/NewtypeWrappersnewtype Fix f = Fix (f (Fix f))「無料」
じゃない？
編集2：
別の一連のベンチマークを実行しました。今回はツリーの構築と分解をテストしました。ベンチマークはこちら: https://dl.dropboxusercontent.com/u/2359191/2014-05-15-kdtree-bench-03.html
Core の出力は、中間データ構造が完全に削除されていないことを示しており、現在は線形検索が優勢であることは驚くべきことではありませんが、KDTreeFs は s よりわずかに高速ですKDTree。あまり関係ありませんが。
