Пределы роста

[metaclass]

Исходник на хаскеле, 2.8 мега, 6000 строк, экспорт из базы данных. GHC при компиляции падает с переполнением стека.

PS: Собралось:

D:\Programm\Haskell\ghc-6.10.2\bin\ghc.exe --make -o test2.exe "test2.hs" +RTS -K100000000
В процессе сожрало 1.5 гигабайта памяти :)

Екзешник получился 43 мегабайта. Отрабатывает сортировку списка и вывод проекции из него достаточно быстро.
Теперь мне пришло в голову, что можно сделать экспорт в более гуманный формат (CSV или вообще бинарный), а из метаданных, которые живут в базе, сгенерить его читалку, тогда компилироваться будет быстро, и можно будет проверить на больших объемах данных.

Comments

[dmzlj.livejournal.com]

Ага, сказали суровые сибирские мужики.

[kiryl.livejournal.com]

Софт вообще дерьмо.

[zelanton.livejournal.com]

ололо
http://lurkmore.ru/Haskell

[potan.livejournal.com]

Без оптимизации?

[migmit.vox.com (from livejournal.com)]

Сделай доброе дело, добавь тикет.

[vromanov.livejournal.com]

нафиг-нафиг.. Еще и с такими глюками бороться...

[clayrat.livejournal.com]

я ж грил надо было в commonlisp гнать =D

[potan.livejournal.com]

Теперь то же самое с -O3 :-)

А вообще вполне приемлемое решение - выдавать отчет ввиде программы, которая осуществляет по нему навигацию. Ночью компилируется, а днем запускается.

[thedeemon.livejournal.com]

>В процессе сожрало 1.5 гигабайта памяти :)

А вот это уже характерно. Когда лучшая программа на Хаскелле (которую всегда называют при просьбе показать большой проект) ест столько памяти на небольшом и довольно безобидном инпуте. Real World Haskell как он есть.

[thedeemon.livejournal.com]

Сейчас для сравнения сгенерил исходник с 6000 туплами по 27 элементов (инты, флоаты и строки) и скормил его Окамлу.
Компиляция в байткод заняла 3 секунды и 32 мега памяти.
Компиляция в нативный код заняла 19 секунд, из которых секунды 3 работал окамл, а все остальное время - масм. Памяти съел 37 мегов.
Значит, проблема не Хиндли-Милнере.