Производительность ленивых структур Clojure против хэшей / наборов / векторов?

Question

Я использую структуры данных Clojure повсеместно, но я не использую ленивую оценку.Есть ли снижение производительности за использование ленивых структур везде?

Answer 1

Из исходного кода:

clojure.lang.Cons (строгий элемент списка, clojure.lang.PersistentList очень похож), https://github.com/clojure/clojure/blob/1.2.0/src/jvm/clojure/lang/Cons.java#L34

public Object first(){
    return _first;
}

clojure.lang.LazySeq (ленивый элемент последовательности), https://github.com/clojure/clojure/blob/1.2.0/src/jvm/clojure/lang/LazySeq.java#L77

public Object first(){
    seq();
    if(s == null)
        return null;
    return s.first();
}

, где

final synchronized Object sval(){
    if(fn != null)
        {
        try
            {
            sv = fn.invoke();
            fn = null;
            }
        catch(Exception e)
            {
            throw new RuntimeException(e);
            }
        }
    if(sv != null)
        return sv;
    return s;
}

final synchronized public ISeq seq(){
    sval();
    if(sv != null)
        {
        Object ls = sv;
        sv = null;
        while(ls instanceof LazySeq)
            {
            ls = ((LazySeq)ls).sval();
            }
        s = RT.seq(ls);
        }
    return s;
}

Значит, вы определенно платите цену. От каждого конкретного случая использования зависит, насколько эта цена влияет на вас и компенсируется ли это экономией памяти и отсутствием потраченных впустую вычислений, что ленивая оценка покупает вас.

Answer 2

Это накладные расходы на ленивые структуры (ответ pmjordan хорош для того, чтобы дать вам кровавые подробности .....). Моя очень приблизительная оценка - вы платите штраф в 2-5 раз.

Однако есть и некоторые плюсы:

• Ленивая оценка означает, что ваш рабочий набор данных может быть меньше, поскольку он создается только при необходимости. Это может улучшить использование кэша и, следовательно, производительность в некоторых случаях
• Ленивая оценка поможет вам написать более простой и понятный код. Таким образом, вы можете сосредоточить свое внимание на написании лучших алгоритмов. Выгода от наличия лучшего алгоритма (например, O (n log n) против O (n ^ 2)) может стоить намного больше, чем накладные расходы на ленивую оценку

Мой совет - использовать ленивый анализ свободно, если вы не уверены, что находитесь в ситуации, когда вам действительно нужна высокая производительность и вы не можете позволить себе дополнительные затраты (например, обработка изображений или что-то в этом роде ...)