Pull to refresh

Comments 13

Хотелось бы отметить, что скорость "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 выражения (запросы) для получения результата, которые чаще всего возвращают именно коллекции.
Таким образом нужно приводить результат к массиву для объективности. При этом отрыв некоторых библиотек уже становиться не таким значительным.
Возможно, в названии статьи по смыслу более адекватен термин «выборка», нежели «выбор».
Показывайте любые тесты, всё равно jQuery не брошу.
Да, кто-к чему «присосался», тот на том и останется. Нет смысла переделывать, если и так всё работает.
Представть плиз формулу расчета среднего значения.
среднее значение = сумма (ускорение_для_каждого_браузера * доля_браузера_по_Яндексу)
ускорение_для_каждого_браузера = сумма (ускорение_для_каждого_селектора * доля_селектора_в_CSS_файле)
ускорение_для_каждого_селектора = время_выборки_селектора_максимальное - время_выборки_селектора_для_текущей_библиотеки

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

Articles