LINUX.ORG.RU

История изменений

Исправление praseodim, (текущая версия) :

Какие другие более быстрые и кросс платформенные языки с хорошими библиотеками/фреймворками, заточенными под работу с юникодом и xml вы бы выбрали и почему?

C# - и кроссплатформенный и библиотеки для работы с xml из коробки и с юникодом все нормально и довольно быстрый, если правильно применять. Со строками работа из коробки нормальная (но не забывать, что если нужна скорость часто полезнее StringBuilder, чем просто String)

Но подозреваю, что в итоге выйдет не сильно быстрее питона. Если основные потери времени на парсинге.

С такими объемами (до 10Тб) есть смысл сделать свой или полусвой (на регулярных выражениях) парсер под текущую задачу. Например, если надо извлекать данные из некоторых определенных тегов, не надо редактировать и обратно записывать xml-файлы и точно знаешь, что там никто не извращался с представлением, то нафиг все эти полные парсеры xml?

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

Исправление praseodim, :

Какие другие более быстрые и кросс платформенные языки с хорошими библиотеками/фреймворками, заточенными под работу с юникодом и xml вы бы выбрали и почему?

C# - и кроссплатформенный и библиотеки для работы с xml из коробки и с юникодом все нормально и довольно быстрый, если правильно применять.

Но подозреваю, что в итоге выйдет не сильно быстрее питона. Если основные потери времени на парсинге.

С такими объемами (до 10Тб) есть смысл сделать свой или полусвой (на регулярных выражениях) парсер под текущую задачу. Например, если надо извлекать данные из некоторых определенных тегов, не надо редактировать и обратно записывать xml-файлы и точно знаешь, что там никто не извращался с представлением, то нафиг все эти полные парсеры xml?

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

Исходная версия praseodim, :

Какие другие более быстрые и кросс платформенные языки с хорошими библиотеками/фреймворками, заточенными под работу с юникодом и xml вы бы выбрали и почему?

C# - и кроссплатформенный и библиотеки для работы с xml из коробки и с юникодом все нормально и довольно быстрый, если правильно применять.

Но подозреваю, что в итоге выйдет не сильно быстрее питона. Если основные потери времени на парсинге.

С такими объемами (до 10Тб) есть смысл сделать свой или полусвой (на регулярных выражениях) парсер под текущую задачу. Например, если надо извлекать данные из некоторых определенных тегов, не надо редактировать и обратно записывать xml-файлы и точно знаешь, что там никто не извращался с представлением, то нафиг все эти полные парсеры xml?

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