Для по сравнению с Doseq (и слишком большой код метода)

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

Реализация doseq внутренне использует функцию, которая рекурсивно создает серию вложенных конструкций loop, по одной loop для каждого уровня привязок в doseq. В простой, неоптимизированной версии этой реализации цикл на каждом уровне просто запускал бы свое тело, а затем вызывал бы recur со значением next для своей последовательности. Что-то в этом роде:

(loop [s (seq input)]
  (if s
    (do (run-body (first s))
        (recur (next s)))))

Однако, если эта последовательность окажется фрагментированной последовательностью, это приведет к ненужному созданию большого количества промежуточных объектов последовательности, которые никогда не используются вне тела цикла. Оптимизация, сделанная doseq, состоит в том, чтобы поместить if внутри loop с одной ветвью для обработки секвенированных последовательностей и одной для обработки нефрагментированных последовательностей. Тело цикла дублируется между каждой ветвью. Если тело цикла оказывается вложенным циклом, то вы можете видеть, как происходит экспоненциальное увеличение размера кода — цикл на каждом уровне расширенного кода имеет два дочерних цикла.

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

Вы можете воспроизвести семантику глубоко вложенного doseq с комбинацией for и dorun (не используйте doall, так как это без необходимости сохраняет заголовок последовательности). Это позволит вам обрабатывать любой уровень вложенности с небольшим, но измеримым падением производительности, если вам случится выполнять фрагментированную последовательность в узком цикле.

user> (time (doseq [x (range 10000) y (range 10000)] (* x y)))
"Elapsed time: 2933.543178 msecs"

user> (time (dorun (for [x (range 10000) y (range 10000)] (* x y))))
"Elapsed time: 5560.90003 msecs"

У меня была похожая проблема, когда я создавал свой собственный компилятор с использованием java.

Я объявил очень большую матрицу. Для меня решение было разделено на небольшую матрицу. Это просто предложение, возможно, вы можете сделать что-то подобное, например:

(def r (range 1))
(defn foo [a b c d]
   (doseq [e r, f r, g r, h r] (println "Hi")))
(doseq [a r, b r, c r, d r :when (and (= 0 a) (not= 1 b))]
   (foo a b c d))