OCaml.

ээ..perl очевидно..он как для такого и сделан

ничего лучше для парсинга чем сишные строки нет, в плане производительности, конечно

c/c++ не рассматриваю по первому критерию(будет много сложного кода)

Конечно же Common Lisp! Парсеры - сильная сторона Common Lisp.

Любой.

Go /thread

bash + sed + awk

Python

Python3[/thread]

perl

Pascal. Паскаль строки часто быстрее си строк.

perl

тот который знаешь </thread>

Таки да. Хороший парсер называется esrap, но человеку не нужен лисп.

+1к это не тот объём, при котором стоит озадачиваться выбором средства. Подойдёт тупо то, на чём быстрее получится сделать. Практически из перечисленного это питон.

есть достаточный опыт работы с haskell и D, для такого утверждения?

Посоветуйте язык для решение

Посоветуйте язык для решения может?

есть достаточный опыт работы с haskell и D, для такого утверждения?

у меня их несколько, какое конкретно утверждение вас интересует?

Практически из перечисленного это питон.

внесу свою лепту

Python.

Go. Можно даже ещё попытаться распараллелить на goroutines (пофайлово хотя бы).

тс, судя по вопросу, ни один из перечисленных не знает, значит придётся учить примерно с нуля. Из всех троих объективно проще выучить быстрее для решения задачи питон.

Знаю python, также писал на D и Haskell, но не много

C/C++. Если второй критерий важен.

огромное число файлов

(1000+)

Хм.

размером 100kb+

Любой.

perl же.

парсить ... (txt, html, xml, ...)

perl ... для такого и сделан

/0 парсинг в понимании перла и тот, который описан в теме, не совсем находятся в консонансе, мягко говоря

В зависимости от того что ты считаешь парсингом и его результатом. В любом случае не D и не Perl. D на такой задаче будет смотреться как C++, а Perl безусловно язык очень весёлый, но через неделю после написания ты не сможешь сам себе объяснить как и вообще что делает этот скрипт. Я бы выбрал Haskell, но Python иногда говорят тоже ничего.

зато кода небось будет ЕЩЁ больше

Я бы взялся делать такую задачу на scala, но она вроде бы прожорливая (java и jvm). зато реально на строках кода (и на нервах) сэкономить можно... и быстро написать

подумываю что haskell подошёл бы хорошо.. а как там с производительностью? вроде бы в машинный код компилирует, да?.. можно ли где прочитать сравнение производительности кода на разных задачах с другими ЯП?

подумываю освоить haskell, но пока не до этого.

Насчёт D точно не скажу.

про python особо хорошего сказать не могу... ну парсер я бы на нём смог осилить, но язык меня некоторыми вещами разражает, в частности своей многословностью, этими подчёркиваниями и вечным self.<что-то>

Понятно, что haskell - не то, что нужно учить, чтобы быть востребованным на рынке труда - вакансий почти и нет.

А вот как haskell именно в плане «есть задача - надо сделать»? Если «для себя», например. Вроде бы очень мощный чистый функциональный язык... Как с производительностью кода/скоростью компиляции (уже выше вопрос задавал).

Показался сложноватым, когда первый раз на него глядел.. но думаю просто надо вложить в него время и усилия.. и всё будет ровно.

Кстати, вообще очень странное утверждение. К сожалению, не представляю как строки реализованы в паскале... в си это обычный массив с \0 на конце. То есть «просто донельзя». Никаких усложнений, которые могли бы «вдарить» по производительности.

Во всяких высокоуровневых ЯП по типу питона... строки занимают дохрена байт.. из-за того что много лишнего что ли хранят... каждая переменная = объект. ну и т.п. и тут можно понять издержки.

а паскаль с сями (по производительности) думаю не должны отличаться.

вот по скорости написания кода - не знаю, может быть и есть отличие..

поправьте, если не прав

Этот говнокодеришка про то, как он постоянно дёргает strlen().

В школе сказали?

Это тебе в школе сказали? Дописать в начало длину «строки» - не проблема, а уж использовать 2 указателя - ещё меньшая проблема, но проблема не в этом, а вернее её как таковой нет, ибо причина в твоём уровне чуть ниже дна и полным не знанием матчасти. Сказать такое может только полный идиот, ибо а) паскаль тормазней раз в 100( это связано с ущербностью самого языка, его синтаксиса, его комьюнити, а так ущербностью всех его реализаций), б) паскаль строка в 99% случаев тормазнее Систроки, ибо в 99% операций длиннах строки не нужна.

Я понимаю, если бы ты сказал «„паскаль-стайл“ строки вроде как „быстрее“», без упоминания самого паскаля, но ты же - ёперный театр.

В парсингре не особо юзается strlen(), а во вменямой работе со «строками» она вообще не юзается, ибо почти все сложные операции делают посимвольным перебором(лёгкие, типа strchr() делаются хитро и быстро - минимум раза в 3-4быстрее, чем посимвольный перебор), и в этом случаа if(ch) будет быстрее цикла со счетчиком, который напишут 99% паскалистов и я даже не знаю сделает ли конпелятор из этого говна более вменяемую конструкцию, типа:

do {
} while(++i != end);

Дальше в школу писать говнище не паскале и не суваться в приличное общество.

пока я писал - опередил, а я так старался рассписывал.

язык на котором уже решена твоя задача в библиотеке.

и/или язык который к лёгкостью может использовать таковую библиотеку.

следовательно любой.

указаные тобой обьёмы (нижняя граница близкая к верхней т.е сумарно порядко 1/10 гигобайта ) -

какая верхняя граница по времени?

тьфу, ну ежу понятно, что сложность strlen будет 0(n), если строка в си-стиле.

ах да... вспомнил. в паскале, кажется, это массив... у которого в нулевом элементе хранится размер строки, а с первого идёт собственно строка... помню.

честно, не уверен, что это хороший дизайн. а если длину строки надо хранить, это можно делать и явно..

Всё просто.

стринга в плюсах - пасклаьстайл. Т.е. стринга знает свою длинну.

Почему такое пошло, когда-то в бородатые года, когда в сишку пришли ламерки(бывшие паскалисты и прочие дегроиды) - они писили свою strlen как говно, с посимвольным перебором и прочим говном, а потом сравнивали его с «паскалькой» реализацией(на сишке, либо на самом паскале). С этого и пошел этот миф.

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

Scala хороша, да. Надо еще ею позаниматься хорошенько.

подразумевается , что при наличии инфы о размере строки

некоторые задачи можно решить более быстрыми методами.

т.е в с прикручиваем отдельное хранения длин .

в паскале открутить учёт длин можно - отказавшись от изпользования строк и исползовать чисто массивы символов.

т.е и там и там быстро и медлено - зависит от реализатора.

Если производительность не критична, спрашивай у левой пятки. Я бы взял питон.

Я, если честно, не понял в чём состоит вопрос. Скорость компиляции как не крути выше чем у плюсов. К производительности кода как правило претензий не возникает. Если писать плохо — код работает медленно, если хоть чуть-чуть отдавать себе отчёт в том что ты пишешь — код работает нормально, если упереться — будет работать быстро, если всё совсем плохо — можно дёрнуть код на C.

а паскаль с сями (по производительности) думаю не должны отличаться.

В паскале кроме самой строки хранят длину. Собственно, все ускорение заключается в отсутствии необходимости прохода по строке при вычислении длины. В остальном разницы нет.

Если не быдлокодить, и не вызывать, например, strlen в цикле, то разницы не будет.

В любом случае, парсинг строки что на си, что на паскале — вещь малоприятная (тем более если там xml или html). Про хаскель ничего сказать не могу, но раз спрашиваешь, то ты на нем, видимо, не писал. Значит, резко начать писать в функциональном стиле вряд ли сможешь. Итого, остается питон. Тем более инструменты для парсинга xml есть в стандартной библиотеке. Для html рекомендую html5lib.

ну и зачем ты тут написал о своих личных проблемах? Нечего сказать по делу — промолчи

Четкого времени нет. Чем быстрее, тем лучше. Однако можно пожертвовать производительностью в угоду легкости написания и тестирования кода.

Необходимо парсить огромное число файлов(1000+) с текстом(txt, html, xml, ...) размером 100kb+ и сохранять результат парсинга.

man awk

Python

Сложный парсинг текста на awk? Вы шутите?

<сарказм> Уж лучше тогда на C без циклов, но с goto и дефайнами ;) </сарказм>

Сложность strlen не совсем O(n=e), в сишке(да и вездее, кроме бесполезных теорий) школьные представления об О-нотации бесполезны.

О-нотация напрямую зависит от реализации, и говорить «теоретически» тут бесполезно, можно выделить какие-то общие вещи, аля n*2 ~=(когдакак, но в среднем равна) time(n)*2, но зачем тогда привязка к n и O-натция вообще?

Одна из реализация strlen() в той же глибц - это ступеньки с шагом 16. Т.е. тут n = это 16символов, а не один. В том же посимвольном переборе n - это символ. Различаются они в производительности овер 2раза.

Вот в чем суть упоминания про О-натацию? Объясните м не?

Про паскаль-стайл строки и их реализацию:

Ну это напрямую связано с неосиляторством паскалистов, и немощности его создателей. Боязнь записи вида *(uint64_t*)str;, типа str[0] круче.

По поводу явно потипу плюсостайла - это лишний указатель на каждую строку.