avp.mkБольшой Синий КитBlackGnomeГуест,

Если нужно высокопроизводительное решение, то Pattern лучше не использовать.
А что использовать? В цикле перебирать символы строки?

Если для задачи хватит одного перебора строки - то да.

avp.mkзабыл никЕсли для задачи хватит одного перебора строки - то да.
А если нет?)

А если нет - то нет естественно:)
Все зависит от задачи, например я выбираю наиболее затратную операцию и делаю перебором - остальные можно и паттерном, или заранее разбиваешь строку на несколько(по смыслу) и работаешь с ними в параллели. ну и т.п. - повторюсь, от задачи зависит.

Joe Rзабыл ник
Все зависит от задачи, например я выбираю наиболее затратную операцию и делаю перебором
А как выбираете, на глаз или специальными средствами?

Обычно это понятно из контекста. Ну смотри у меня была задача распарсить sql-строку запроса(перевести в lower-case добавить кое-где пробелы, кое-где убрать и т.п.) далее, в зависимости от того есть ли в строке limit x offset y - получить числа x и y(для того чтобы достать из кэша только нужные данные), далее заменить все что внутри {#...} на какие то данные. и еще много чего. Эта задача не решалась обходом одной строки, ну может и решалась, но слишком много состояний(кэш включен или нет, есть что замещать или нет, есть лимит или нет...). Был выбран вариант - оптимизировать наиболее частый случай, в предположении что нету лимитов, кэша и т.д - он реализован перебором строки. Если же во время перебора выясняется что все сложнее - то строку получившуюся после первого прохода(все в lower-case пробелы расставлены, eq заменено на == и т.д) - уже прогоняем через паттерны всякие.

Joe Rзабыл ник,

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

Ну в общем-то тоже правильно, но зачастую нужно учитывать саму задачу.
Например, профайлер показал что наиболее частый случай -
1. строка в которой нет limit, но есть #{} - 45%
2. строка - где нет ничего особенного - 37%
3. остальные - 18%

Если решать в лоб - то надо бы оптимизировать первый вариант, но по логике задачи - строку в ЛЮБОМ случае надо привести к общему виду(,без лишних пробелов и ловер кейс, замена eq на ==.... etc.), оптимизировать вариант 1 - приведет к большой мешанине кода, вариант 2 - буквально на чуть-чуть упадет производительность в наиболее частом случае, зато код читаем и легко управляем.. Без компромиссов никак:)