Я постоянно встречаю рекомендацию использовать, когда это разумно, обычный поиск вместо регулярных выражений, поскольку последние сильно медленнее. Но никогда не видел насколько медленнее и когда они становятся эффективнее. Но зуд покоя не дает и я решил сравнить их и посмотреть какие циферки можно увидеть в реальности…
Итак, берем обычную страничку и делаем поиск строчки в ней. Я взял собственный document и искал в нем id на кнопке «run_test». Выглядит это банально:
Итак, берем обычную страничку и делаем поиск строчки в ней. Я взял собственный document и искал в нем id на кнопке «run_test». Выглядит это банально:
for(i=0;i<100000;i++) { string.indexOf('run_test'); }
и
for(i=0;i<100000;i++) { string.search('run_test'); }
* This source code was highlighted with Source Code Highlighter.
Но, поскольку нелегкая дернула меня взять id я подумал и добавил для сравнения выборку элемента обычную и jQuery
for(i=0;i<100000;i++) { $('#run_test'); }
и
for(i=0;i<100000;i++) { document.getElementById('run_test'); }
* This source code was highlighted with Source Code Highlighter.
Ну и попробовал это на разных браузерах:
Смотрим на результат и делаем выводы:
Во-первых, прямой поиск больше чем на порядок быстрее регулярки, что означает что 2-3, а то и с десяток indexOf вместо search будут «оправданы», но в реальности, если их не тысячи в загруженных циклах, такая оптимизация не даст эффекта.
Во-вторых, Chrome реально шустрый :) И если FF, показывая те-же цифры на indexOf практически отрубился от внешнего мира внутри циклов, то Chrome продолжал весело крутить гифчик и в целом его не удалось подгрузить такими простыми вещами. Opera похоже выбрала разумный компромис, нормально отрабатывая события и моргая картинками, не особенно тормозя на регулярках.
FF имеет еще какую-то странность — первые несколько тестов показывают хорошую скорость на регэкспах, но потом скорость падает более чем в два раза. Может он решил что данный скрипт слишком его грузит?
Далее jQuery. Несмотря на то что в конце концов id находиться через getElementById, перед этим делается несколько проверок и все на регэкспах. Конечно почти 20 микросекунд погоды не делают, но это еще один довод в пользу цепочек методов.
Цифры для IE — в районе 70… на таких примитивных тестах, конечно, нельзя ничего сказать определенного, но относительно резкое падение производительности, при небольшом увеличении сложности обычно говорит о излишне запутанной архитектуре. Если не брошу это бестолковое занятие, надо будет проверить наличие полки при средних по сложности тестах — это будет означать излишне большое количество опций. Либо будет безудержный рост :) IE он такой — он может! :)
Немного удивило то что getElementById оказался таким неторопливым.
В качестве бонуса — можно пощупать и посмотреть оригинальный скриптик. Дополнения и замечания приветствуются.
