5 мая 2008 в 11:24

Скорость выборки CSS-селекторов в JavaScript-библиотеках

Наряду со сравнительными тестами времени загрузки различных JavaScript-библиотек было интересно посмотреть, насколько оптимизированы в них наиболее популярные действия, а именно: выбор элементов по CSS-селекторам. Ведь даже в простейшем JavaScript-коде на основе таких библиотек используется, порой, несколько десятков таких операций, не говоря уже о сложных интерфейсах и полноценных веб-приложениях.

Приведу характерный пример кода для jQuery, который использует движок CSS-селекторов:

$(function(){
    $("a.clip").click(function(){
        $("#clip"+$(this).attr("rel")).slideToggle(500);
        if($(this).html() == "+") {
    $(this).html("–");
        } else {
    $(this).html("+");
        }
        return false;
    });
})


читать дальше на webo.in →
Николай Мациевский @sunnybear
карма
331,0
рейтинг 28,0
Технический директор, Айри.рф
Похожие публикации
Самое читаемое Разработка

Комментарии (13)

  • –1
    В FF2 base2 быстрее DOMAssistant ;)
  • +1
    Хотелось бы отметить, что скорость "CSS-движка" очень зависит от структуры HTML.
    Но более важно стоит отметить, что различные библиотеки отдают разный тип результата. Некоторые отдают массив элементов, а некоторые коллекции. Разница в том, что в первом случае расходы на обработку коллекции закладываются в результат, а во втором случае, расходы появляются при первом обращении/обработке коллекции. Надеюсь вы это учитывали?
    ---
    объясню на примере
    1. затраты на этапе выборки

    function getAllElement(){
    var nodes = document.getElementByTagName('*');
    var len = nodes.length
    var result = [];
    for (var i = 0; i < len; i++)
    result.push(nodes[i]); <-- основные издержки здесь
    return result;
    }
    var nodes = getAllElement();
    for (var i = 0; i < nodes.length; i++)
    {
    var node = nodes[i];
    ...
    }

    2. затраты на этапе обработки

    function getAllElement(){
    return document.getElementByTagName('*');
    }

    var nodes = getAllElement();
    for (var i = 0; i < nodes.length; i++)
    {
    var node = nodes[i]; <-- основные издержки здесь
    ...
    }

    ---
    При этом оба куска кода выполнятся примерно за одинаковое время. Но в данном (как и в других) тесте Вы замеряете работу только getAllElement (getAllElement в данном случае пример функции для наглядной демонстрации).
    Изучая работу и скорость выборок различных библиотек я пришел к такому выводу, что некоторые библиотеки значительно "выигрывают" в части тестов на этом нюансе (к примеру тот же base2). Заметим что тип результата (массив или коллекция) зависит не только от библиотеки, но от окружения (браузера) в котором она исполняется, а так же от типа запроса (CSS селектора). Так часть библиотек используется XPath выражения (запросы) для получения результата, которые чаще всего возвращают именно коллекции.
    Таким образом нужно приводить результат к массиву для объективности. При этом отрыв некоторых библиотек уже становиться не таким значительным.
  • +2
    По ссылке вначале статьи страница не найдена: http://webo.in/articles/habrahabr/20-jav…
    Ссылка на DOMAssistant тоже устарела, новая: http://www.domassistant.com/
    За статью спасибо, почитаю, что за DOMAssistant и base2.
  • +1
    Возможно, в названии статьи по смыслу более адекватен термин «выборка», нежели «выбор».
  • +1
    Показывайте любые тесты, всё равно jQuery не брошу.
    • 0
      Да, кто-к чему «присосался», тот на том и останется. Нет смысла переделывать, если и так всё работает.
      • +1
        Indeed
  • +1
    Представть плиз формулу расчета среднего значения.
    • +1
      среднее значение = сумма (ускорение_для_каждого_браузера * доля_браузера_по_Яндексу)
      ускорение_для_каждого_браузера = сумма (ускорение_для_каждого_селектора * доля_селектора_в_CSS_файле)
      ускорение_для_каждого_селектора = время_выборки_селектора_максимальное - время_выборки_селектора_для_текущей_библиотеки

      надеюсь, это более-менее понятно
      • 0
        Это не очень логично. Если добавить в тестирование ещё одну библиотеку, которая будет работать оооооочень медленно и везде займёт последнее место (надеюсь, ясно, что написать такую библиотеку легко), то все результаты резко изменятся. Лучше уж считать замедление относительно самого быстрого результата.
        • 0
          если честно, разница не очень большая. Т.е. или от 100% отнимать долю, или к 0 эту же долю прибавлять. С другой стороны, не очень удобно переходить от одного набора библиотек к другому — но отсчет "от нуля" не решит эту проблему (ибо может так же появиться библиотека, которая "быстрее всех").
          • 0
            Есть некоторый идеал минимального времени, потраченого на выборку селекторов, который, вероятно, не достигнут. Считать проценты логично бы было от него, но мы это минимально возможное время, к сожалению, не знаем. Минимальное достигнутое время является хорошим к нему приближением, а вероятность появления новой библиотеки, которая всех порвёт по времени, довольно мала. С другой стороны, максимальное время - это некоторая фикция, зависящая только от выбора библиотек, и нормаровать по нему плохо.
  • 0
    Упс, спасибо застатью, я в шоке был от результатов решил проверить. Еще пару месяцев назад prototype был быстрее, потому я долго не хотел перебираться на jquery, оказывается пора :(.
    вот замечательный тест.
    http://mootools.net/slickspeed/

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