В нашем случае с MediaWiki мы получили выигрыш в поиске подстрок примерно в 500 раз, а с учетом того, что это занимало ~75% времени — мы получили выигрыш производительности примерно в 4 раза.
А вообще в более-менее нормальном проекте будет ли выигрыш? Прям все хайлоады str_replace в каждой второй строчке используют и это самое тонкое место?
Если все так круто, то чего б авторам не протолкнуть алгоритм в основную ветку php.
А вообще от статейки идет душок НЛП и оптимизаторства.
В более-менее нормальном проекте, все " проблемные строковые функции" падают в кеш - серверный и\или браузерный. Поэтому означенных проблем просто нет. И решать их, значит, не надо.
имхо
str_replace + аналоги достаточно используемые в шаблонных системах представления и являются действительно одним из ключевых нагрузочных мест к примеру при парсинге шаблонов, особенно если шаблоны насыщены каким либо "метаязыком".
выше же написали, что все в кэш ложится.
шаблоны без кэширования (когда постоянно приходится их парсить) - это уже проблема головы, а не строковых функций
Автор оригинала: Crys
выше же написали, что все в кэш ложится.
шаблоны без кэширования (когда постоянно приходится их парсить) - это уже проблема головы, а не строковых функций
1. препарсинг шаблонов (минимизация нагрузки при реальной подстановке)
2. кэширование контента (для того, чтобы выдать страницу из кэша, шаблонизатор вообще не нужен)