2

私の質問は、.csvファイルが十分に大きい場合、map / zipmapステップ（下記）はメモリを消費しすぎるリスクを冒しますか？

clojure-csvからシーケンスのシーケンスが返されました。以下の手順は、わかりやすくするために意図的に分けられています。言い換えれば、私はこれらのいくつかを本番コードで組み合わせることになります。

; Process the .csv file
(defn fetch-csv-data
    "This function accepts a csv file name, and returns parsed csv data,
     or returns nil if file is not present."

    [csv-file]
        (let [csv-data (ret-csv-data csv-file)]
            csv-data))

(def bene-csv-inp  (fetch-csv-data "benetrak_roster.csv"))

; Pull out the columns/keys, and
(def bene-csv-cols (map #(cstr/trim %1) (first bene-csv-inp)))

; create the keys.
(def bene-csv-keys (map #(keyword %1) bene-csv-cols))

; Make a sequence of just one of the keys:

(def test-ssns2 (map (fn [x] (:GIC-ID x)) 
                (map #(zipmap gic-csv-keys %1) gic-csv-data)))

ありがとう。

4

1 に答える 1

4

このコードがメモリをリークする唯一の方法は、defs が遅延シーケンスの先頭を保持するためです。それらをシーケンスを返す関数に置き換えると、実際のヘッドはコールスタックにのみ存在し、遅延評価によって適切に処理されます。

(defn bene-csv-inp [] (fetch-csv-data "benetrak_roster.csv"))

; Pull out the columns/keys, and
(defn bene-csv-cols [] (map #(cstr/trim %1) (first (bene-csv-inp))))

; create the keys.
(defn bene-csv-keys [] (map #(keyword %1) (bene-csv-cols)))

大まかな経験則ですが、無限のシーケンスが含まれている場合は 's に置き換えdefs、defn読み取りの代わりにどこでも呼び出されるようにすることをお勧めします (複数のリーダーに対して遅延シーケンスのキャッシュの利点が本当に必要で、シーケンスが妥当な量のデータのみが読み込まれます)。

ここで定義を読み取る代わりに関数呼び出しを使用しても、ホットスポット コンパイラが処理を終了すると、ほぼ確実にランタイムに影響を与えません。

于 2012-08-09T18:49:49.883 に答える