Комментарии 33
в FF при первой загрузке метод jQuery отрабатывает быстрее search, а по кнопке jQuery уже отстаёт на порядок от всех. Что это с ним?
> Я взял собственный document и искал в ней id на кнопке «run_test».
ничерта не понял.
в ней — это в document? id на кнопке это что?
ничерта не понял.
в ней — это в document? id на кнопке это что?
и почему вы сравниваете indexOf() и getElementById(), у них разве есть что-то общее?
Теоретически можно искать содержимое элемента, например, и с помощью обычного поиска. Но честно говоря мне хотелось посмотреть скорость выборки. Может быть интересное будет, если сравнивать на огромном документе, поскольку время поиска будет расти линейно от размера, а для захэшированной заранее структуры по логарифму. Но… ладно, забыли, мне просто хотелося :)
Это — document, спасибо исправил.
<input id="run_test" type="button" value="Run test"/>как в document можно искать строку? это же объект.
категорически не понимаю смысл проведенного теста.
категорически не понимаю смысл проведенного теста.
Ну и что? объект может иметь представление в виде строки. Собственно он и был текстовым файлом до парсера.
Но в данном случае document, точнее его innerHTML — просто предмет для тренировки поиска.
Но в данном случае document, точнее его innerHTML — просто предмет для тренировки поиска.
Мне определенно не ясен ход Ваших мыслей.
Смотрите, фактически у Вас два никак не связанных между собой теста «indexOf vs search»¹ и «getElementById vs $()»², результаты которых, по непонятной мне причине отображены на одном графике.
При этом, оба теста, как мне кажется не совсем, мягко говоря, корректные.
¹Разумеется search медленее indexOf для приведенного Вами варианта, но тут нужно упомянуть, что search по строгому выразению «run_test» смысла не имеет, кому придет в голову в такой ситуации воспользоваться search? Если бы было дано регулярное выражение /run[_-]?test/i, напрмер, это было бы понятно и оправдано, но тогда отпадает indexOf. Вообщем, по-моему Вы сравнили не сравниваемые вещи.
²Само собой $() медленее getElementById, и опять же, как и в случае ¹ они служат для разных целей, даже при выборке по id в обоих случаях не стоит забывать, что первое вернет jQuery объект (который еще необходимо создать), а второе вернет dom element.
Смотрите, фактически у Вас два никак не связанных между собой теста «indexOf vs search»¹ и «getElementById vs $()»², результаты которых, по непонятной мне причине отображены на одном графике.
При этом, оба теста, как мне кажется не совсем, мягко говоря, корректные.
¹Разумеется search медленее indexOf для приведенного Вами варианта, но тут нужно упомянуть, что search по строгому выразению «run_test» смысла не имеет, кому придет в голову в такой ситуации воспользоваться search? Если бы было дано регулярное выражение /run[_-]?test/i, напрмер, это было бы понятно и оправдано, но тогда отпадает indexOf. Вообщем, по-моему Вы сравнили не сравниваемые вещи.
²Само собой $() медленее getElementById, и опять же, как и в случае ¹ они служат для разных целей, даже при выборке по id в обоих случаях не стоит забывать, что первое вернет jQuery объект (который еще необходимо создать), а второе вернет dom element.
1. Для сравнения чуть более сложного выражения пришлось бы его реализовывать на обычном поиске, было бы несколько вариантов. Например для /run[_-]?test/i можно искать «run», потом проверять следующие символы или искать 3 варианта. Это без учета case.
Я сделал примитивное сравнение эквивалентных для кода операций. Просто сейчас смотрю на реализации регулярок и показалось что в вырожденном случае, на простой строке, регэксп должен выдать нечто близкое к Алгоритму Бойера — Мура
Похоже что нет. Или может быть для регулярок имеется излишний оверхэд.
2. Да, но насколько? Учитывая что для id jQuery использует getElemntById. К стати свой обьект по элементу jQUery делат за время, значительное меньшее полученного оверхэда. Зато делает проверку полуенной строки регэкспом :)
Я сделал примитивное сравнение эквивалентных для кода операций. Просто сейчас смотрю на реализации регулярок и показалось что в вырожденном случае, на простой строке, регэксп должен выдать нечто близкое к Алгоритму Бойера — Мура
Похоже что нет. Или может быть для регулярок имеется излишний оверхэд.
2. Да, но насколько? Учитывая что для id jQuery использует getElemntById. К стати свой обьект по элементу jQUery делат за время, значительное меньшее полученного оверхэда. Зато делает проверку полуенной строки регэкспом :)
Смысл — сравнить обычный поиск подстроки и регулярное выражение. Понять насколько тяжелым бременем является бездумное использование регэкспов для простого поиска. Понять имеет ли смысл иногда преобразовывать регулярное выражение в цепочку простых indexOf.
Ответ — можно не париться.
Ответ — можно не париться.
> Ответ — можно не париться.
Учитывая резулататы, которые показывают, что search в 5-10 раз медленее даже для точного выражения, весьма странный вывод.
Учитывая резулататы, которые показывают, что search в 5-10 раз медленее даже для точного выражения, весьма странный вывод.
JS — не тот инструмент, на котором будет видна разница замены search на indexOf. Я это вижу практически и просто хотел в этом убедиться.
Если лопатиться много текста, то эффективней скинуть его на сервер и получить результат, чем мучиться с реализацией регулярки в виде элементарных манипуляций с текстом.
Разница для 100 000 поисков — 0.7 секунды. Если вдруг встала такая проблема то сначала придется решить проблему с молчаливой недоступностью FF и IE на таких выборках.
Если лопатиться много текста, то эффективней скинуть его на сервер и получить результат, чем мучиться с реализацией регулярки в виде элементарных манипуляций с текстом.
Разница для 100 000 поисков — 0.7 секунды. Если вдруг встала такая проблема то сначала придется решить проблему с молчаливой недоступностью FF и IE на таких выборках.
> JS — не тот инструмент, на котором будет видна разница замены search на indexOf. Я это вижу практически и просто хотел в этом убедиться.
Я бы мог бы поспорить с утверждением, что это «не тот инструмент», но не буду, т.к., в отличие от Вас не вижу тут ничего практического. Приведите реальный пример практической задачи, которая может быть решена как с помощью indexOf, так и с помощью search.
> то эффективней скинуть его на сервер и получить результат
Это смотря с какой стороны посмотреть на вопрос. Этим Ыы увеличиваете нагрузку на сервер, и соответственно, повышаете стоимость решения.
Я бы мог бы поспорить с утверждением, что это «не тот инструмент», но не буду, т.к., в отличие от Вас не вижу тут ничего практического. Приведите реальный пример практической задачи, которая может быть решена как с помощью indexOf, так и с помощью search.
> то эффективней скинуть его на сервер и получить результат
Это смотря с какой стороны посмотреть на вопрос. Этим Ыы увеличиваете нагрузку на сервер, и соответственно, повышаете стоимость решения.
Ну например есть шаблон, в котором простые переменные вида %var_name%. Переменных мало — дясяток-другой, встречаться могут где угодно в тексте или в теге.
Можно этот шаблон дернуть одним регэкспом, а можно с десятком-другим indexOf в цикле по массиву переменных.
Про стоимость — зато падает стоимость поддержки :)
Можно этот шаблон дернуть одним регэкспом, а можно с десятком-другим indexOf в цикле по массиву переменных.
Про стоимость — зато падает стоимость поддержки :)
> Можно этот шаблон дернуть одним регэкспом
в смысле дернуть? если это шаблон, приведите пример подстановки значений «одним регэкспом».
в смысле дернуть? если это шаблон, приведите пример подстановки значений «одним регэкспом».
Подстановки, в смысле replace, не получиться, не умеет JS работать с массивами в replace и функция тоже не вставляется.
Получиться цикл с exec. Но в один проход по тексту.
Если менять на indexOf то будет их несколько.
Получиться цикл с exec. Но в один проход по тексту.
Если менять на indexOf то будет их несколько.
Был не прав, функция есть! :)
Выглядеть должно как
Выглядеть должно как
str.replace(/%(\w+)%/,function($0,$1) {return vars[$1]; });я от Вас этот ответ и хотел услышать, но, признаюсь честно, нить своих рассуждений за рабочий день потерял :)
в целом, соглашусь, задачи, где уместно сравнение indexOf и search имеются.
все же, по моему, было бы намного нагляднее и информативнее привести тест с регулярным выражением внутри search (не «run_test») и тогда уже оценить в приближенной к реальности задаче разницу производительности.
например Ваш код, против:
for (key in vars) str.replace("%" + key + "%", vars[key]);
в целом, соглашусь, задачи, где уместно сравнение indexOf и search имеются.
все же, по моему, было бы намного нагляднее и информативнее привести тест с регулярным выражением внутри search (не «run_test») и тогда уже оценить в приближенной к реальности задаче разницу производительности.
например Ваш код, против:
for (key in vars) str.replace("%" + key + "%", vars[key]);
> Ыы
Вы*
простите.
Вы*
простите.
практическая задача — всяческие закладурки (bookmarklets); собственно поиск; проверка форм ввода; всяческое декорирование типа сворачивания внутритекстовых аббревиатур в тэг acronym.
Предлагаю еще сравнить скорость обработки двойных кавычек против скорости обработки одинарных в JS ;)
1. «indexOf vs. search» — можно было и просто алгоритмы сравнить, чтобы увидеть, что .search не может быть быстрее .indexOf'a (это же надо преобразовать аргумент в RegExp (если необходимо), сколько действий в самом конструкторе RegExp'a, вызвать .exec, где тоже много действий). Но, практические результаты — тоже хорошо.
2. «document.getElementById vs. $() из jQuery» — действительно не понятно, каким боком это приплетено к графикам с «indexOf vs. search», но в целом — тоже понятно (если проанализировать код jQuery), что $(), перед тем, как вызовет document.getElementById, делает кучу дополнительных телодвижений и wrapper'ов.
2. «document.getElementById vs. $() из jQuery» — действительно не понятно, каким боком это приплетено к графикам с «indexOf vs. search», но в целом — тоже понятно (если проанализировать код jQuery), что $(), перед тем, как вызовет document.getElementById, делает кучу дополнительных телодвижений и wrapper'ов.
Вы отобрали хлеб у британских учёных.
Вы готовите JS неправильно.
В JS важна не столько скорость выполнения, сколько *разделение времени* (в смысле cooperative scheduling) между потоком отрисовки и потоком JS.
Посмотрите этот пример: www.cs.umd.edu/projects/PL/arrowlets/example-incremental-search.xhtml
Этот пример показывает грамотное разделение времени в JS.
(Ну и другие оттуда же.)
В JS важна не столько скорость выполнения, сколько *разделение времени* (в смысле cooperative scheduling) между потоком отрисовки и потоком JS.
Посмотрите этот пример: www.cs.umd.edu/projects/PL/arrowlets/example-incremental-search.xhtml
Этот пример показывает грамотное разделение времени в JS.
(Ну и другие оттуда же.)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Примитивное сравнение производительности search и indexOf в Javascript