Как стать автором
Обновить

Комментарии 10

Про gopls интересный доклад, только недавно с gopls боролся, никак он не ставился с мутной ошибкой, в итоге помогло снести все go и переставить
Рады, что вам понравился доклад и что получилось решить проблему.
Судя по issue у стандартной библиотеки есть проблемы со скоростью обработки больших XML файлов:
Actually, programmer who coded this library is long gone so we are clueless.

Disclaimer: this is not official excuse, I made it up since community is mysteriously silent on this issue

Кстати, интересная ссылка, спасибо. Я попробую может быть на днях сделать буфер чтения. Это внезапно может вообще помочь. Как-то я пропустил эту часть.

Получилось так, что под Windows парсинг файла порядка 80 МБ (порядка 50000 линейных объектов) занимало около 20 сек, что сравнимо со скоростью vb скрипта с использованием MSXML.
После гугления оказалось, что xml не в фаворе у разработчиков. Все обходятся обёртками над проверенными библиотеками, либо самописные минипарсеры под свои нужды.

Но надо посмотреть. Например про буфер чтения я не подумал. Там по ссылки интересные настройки есть. Возможно ускорящие разбор. Ещё интересно — возможно более детальный разбор тем и лучше :)

У Go в принципе стандартная библиотека для работы с XML так себе и многих банальных вещей тупо не поддерживает. Альтернатив по-моему тоже практически нет. Видимо XML банально больше особо не используют, кроме всякого легаси, но там его Java хэндлит.

Да норм она. Я собственно на go этот разбор сделал, потому что на python умереть мозголомный даже lxml. Perl не умеет потоково (или надо искать). Но да, развития там что-то не видно

Я не смог с её помощью парсить и писать XML-ки с неймспейсами. Для всяких SOAP-сервисов это важно, приходилось через strings.Replace городить костыли.

А ну да. Я неймспейсами вообще никогда не пользовался, за 20 лет не понял в какое они место. Но да, SOAP хочет. А нет разве стандартного решения с SOAP? Это странно

Зарегистрируйтесь на Хабре, чтобы оставить комментарий