Haskell, Parsec 2 и тормоза

[thedeemon]

Помня о том, какое бурление вызвало сравнение скорости Лиспа с другими языками в прошлом номере ПФП, прошу помощи зала не допустить несправедливости. Я сейчас доделываю сравнение скорости разных методов парсинга, сделал вариант на Хаскеле на базе Parsec2, и получившаяся скорость мне совсем не нравится. До этого на Хаскеле не писал, поэтому наверняка мог сильно налажать. Исходник (~70 строк) выложил здесь.
Суть программы - чтение карты формата OpenStreetMap и вычисление ее реальных границ - минимальных и максимальных значений широты и долготы встреченных точек. Собирал ее с GHC 6.8.3 и 6.10.1, Parsec 2.1.0.1, команда для сборки:

ghc -O2 -package parsec bounds.hs -o bounds

Сейчас скорость получается около 3 МБ/с.
Пример простой карты тут. Скорость тестировал на карте Сингапура (архив 1.2 МБ).

Прошу более опытных товарищей глянуть на исходник и указать на явные косяки. Можно ли заметно ускорить программу без сильных изменений описанной там грамматики?

Comments

[nealar.livejournal.com]

Некорректное сравнение. Если сравнивать готовый XML-парсер, то не с парсечной реализацией, а с готовым XML-парсером.

[sleepy-drago.livejournal.com]

разумеется некорректно тк потоковый парсер будет существенно быстрее :) Я просто провел baseline - для перформанса. Там строится полный DOM (это тормоз номер раз) и для каждого нода делается 1 strcmp и 2 atof (это тормоз номер два тк парсер имеет это значение быстрее).

Вот собсно код http://www.everfall.com/paste/id.php?br3cu0ui8ere
(61 строка). Собиралось 10м экспрессом (в пустой проект добавить этот файл и все 4 файлика пуги. Время работы релиза со статикой ~0.17 сек. Результат практически такой же ( другая точность распечатки плавучки ) и я поленился на мессаджи :)

[nealar.livejournal.com]

Да, я тоже думаю, что HaXml будет медленней. Тем не менее, либу их коробки, разбирающую ДОМ, корректно сравнивать с ним. А наколенник на bison - с наколенником на Happy, в крайнем случае на парсеке.