A
не, там в основном расходы идут на gc, поэтому вопрос в том, как сделать так, чтобы промежуточные результаты были максимально пригодны к продолжению вычислений
Size: a a a
2020 July 31
A
кстати еще надо попробовать честный рекурсивный вариант
A
но без tco может стека не хватить
PG
победил однозначно mapcan
A
еще может сработать вариант с деструктивным reverse
PG
попробуй вариант с collect
24, в два раза медленнее nconc
PG
еще может сработать вариант с деструктивным reverse
у меня, кстати, plist в обратном порядке собирается, так что можно и без reverse
A
значит просто в cl-loop нет оптимизаций по сборке результата
VL
а функции были скомпилированы?
A
в обратном порядке там совсем другой подход, надо аккумулятор
VL
в любом случае причина проста
VL
mapcan написан на C
A
ну mapcar тоже написан на си, но тут еще фишка в том, что мапкан наверняка по ходу выполнения держит указатель на хвост собранного списка
VL
но было бы интересно перед бенчем запустить (compile 'alist->plist)
S
Интересно даже стало
A
если бы я писал, я бы так и сделал
PG
кстати еще надо попробовать честный рекурсивный вариант
не хватает max-lisp-eval-depth для auto-mode-alist
PG
а функции были скомпилированы?
нет
A
если надо реверсить, то по-моему зарулит reduce
(reduce (lambda (x acc) (cons (car x) (cons (cdr x) acc))) alist)
(reduce (lambda (x acc) (cons (car x) (cons (cdr x) acc))) alist)