All streams
Search
Write a publication
Pull to refresh
64
0
Богданов Андрей @bay73

Пользователь

Send message
Ну во-первых уже существуют автоматические анализаторы новостей. А во-вторых, активатором могут стать и живые трейдеры — они дают небольшой импульс, а автотрейдинг видит тренд и подключается.
Да я не с претензией, мне просто интересно в какую сторону можно обобщить это исследование. И есть ли какие-то общепринятые термины? Моя дочка, кажется, использовала термин «кратность» вместо «порядок», «обобщенная звезда» вместо «полиграмма», но картинки просто один в один :)
Забавно, но эта статья — практически полное изложение доклада, который моя дочка делала в 6-ом классе. Только некоторые моменты у нее были поподробнее разжеваны.
Ну некоторые браузеры уже сейчас p2p поддерживают. И число таких браузеров будет расти. Так что можно обойтись уже и без установки нового софта.
Как профессиональный решатель и автор разных головоломок могу сказать, что «хэнд-мэйд» задачи всегда лучше, чем автоматически сгенерированные. Хотя и среди автоматически сгенерированных изредка попадаются интересные экземпляры. Посему в соревнованиях по решению головоломок очень редко используются «автосгенеренные» задачи (а если кто-то из организаторов использует, то обычно получает немалую долю крититки от участников).
А вот для тренировочных целей генерация позволяет получить некий материал (я и сам имею пару сотен программ-генераторов) — решение таких задач позволяет приспособиться к задаче и «почуствовать» ее закономерности.
Во-первых, jQuery в первую очередь я бы характеризовал не как «медленную», а как «удобную». Пролизводительность в данном случае вторичный фактор.
Во-вторых, я ничуть не рассматриваю данный тест, как основание для серьезных выводов. Это лишь повод задуматься. Если кто-то возьмется организовать серьезный тест с учетом всех сайд эффектов, то я буду рад посмотреть на его результаты. Правда по собственному опыту могу сказать, что при любой организации тестов «проигравшая» сторона всегда обвиняет организаторов в неправильном подходе к тестированию :)
Вы переоцениваете этот компилятор. На таких простых вызовах, как в тесте компилатор closure не даст выигрыша в производительности. В данном случае на выходе компилятора будет ровно такой же javascript код, как и на входе.
Тут дело не в кэше, а в моих кривых руках — для native я вместо element.className написал element.getAttribute('class').
Попробую ответить
Почему для тестов не использовали проверенный годами benchmark.js (в основе jsperf.com)?
Потому-что мне было проще написать несколько строчек самому и получить готовую отформатированную табличку с результатами.

Во-вторых, использовать методы getElements{ByTagName, ByClassName /*, etc */} можно просто ради интереса (зная что они возвращают «live» NodeList/HTMLCollection, которые малопригодны для чего-то сложнее простых операций выборки/перебора и своих велосипедов). Но тогда где querySelector{All}?
Как я уже писал — для тестов использовались вызовы, которые широко встречаются в имеющемся коде. jQuery селектор вида $('.class') я встречаю очень часто. Естественно пришлось сделать его аналоги (конечно же не полный эквивалент) и для других библиотек.
Ну так с этого я статью и начал — сравнивались функциональные возможности, а вопрос быстродействия был второстепенным. Но эту статью я посвятил именно производительности.
Я старался сравнивать самые простые операции, умещающиеся в одну строчку (да и то, судя по комментам, далеко не везде наилучшим образом написал). Для более сложных вещей найдется уже несколько вариантов реализации на каждой из библиотек. И производительность от выбора вариавнта будет зависеть больше, чем от выбора библиотеки.
Хотя можно было бы организовать своеобразный тест TPC — коллективным разумом выбрать наиболее характерные операции и сравнить их реализации.
Да, в подавляющем большинстве приложений разницы никто не заметит. Но бывают случаи — например, красивый грид с данными на страничке — если каждую ячейку отдельным $.appendChild отрисовывать, то тормозить будет уже заметно.
Точно — в toggle class я className использовал, а вот в read classes почему-то о нем забыл. Спасибо. Разница небольшая, но как раз объясняет скорость ExtJS.
Выше я уже писал — POST, GET слишком сильно от сети и сервера зависят и влияние библиотек померить трудно будет. А вот парсин json попробую к следующему разу добавить.
Время выполнения GET И POST таким образом вряд ли стоит замерять — все-таки там время отклика сервера будет превалюрующим, а вот разбор строк можно померять.
Сразу отвечаю и akira и bolk — зная где взять библиотеку, и как с ее использованием описанные выше операции выглядят — можно легко расширить тест. Займусь этим на досуге. Ну а если любители библиотек пришлют мне вызовы для выполнения операций, аналогичных тем, что в статье, то дело будет быстрее.
Я бы как раз хотел защитить jQuery. :)
Ну а код использовался аналогичному в реальных проектах. Классы элемента получать действительно не очень нужно — об этом и в статье написано. А вот добавление с использованием $('<...>') вижу в каждом втором файле.
Раньше я особо не задумывался о способе написания вызовов в jQuery, да и окружающие, видимо, тоже (судя по исходникам) — тот же css выствляют поочередно каждым из способов. :)

Меня тоже результаты ExtJS порадовали. Но я это списываю на свои кривые руки при вызове native
методов.
Заменил code.jquery.com/jquery-1.10.2.min.js на code.jquery.com/jquery-2.0.3.min.js

Изменения в результатах не заметил.
Спасибо за замечание — добавил указание, того, что это число операций в миллисекунду.

Information

Rating
Does not participate
Registered
Activity