Previous Entry Share Next Entry
2016-01

JS performance ололо

1. Перформанс node.js 0.10 и 0.11 отличается в 16 раз. (0.11 быстрее)

2. Каждый следующий перезапуск теста проходит медленнее
(То же справедливо и для браузеров)

3. В целом, у разного кода на разных браузерах перформанс fucking random. Особо радует то, что он нелинейно зависит от размера входных данных, даже не монотонно, иногда различается в 3-5 раз.

4. В патологических случаях бывает разница и в 40 раз.

5. Нет, сейчас нету браузера, который быстрее. Есть только либы, заточенные под разные браузеры. Можно сделать чтобы IE всех рвал в 10 раз, можно FF, можно Chrome, как угодно.

(Я не знаю, что делать с этим знанием)

This entry was originally posted at http://wizzard.dreamwidth.org/379565.html. It has comment count unavailable comments. Please comment there using OpenID.

  • 1
justy_tylor July 4th, 2014
Дойдёт до маразма - код будут писать под emscripten, а для него наплодят кучу драйверов ("драйвер компенсации глюков хрома", "драйвер компенсации глюков ие11", ...).

_winnie July 4th, 2014
1) Можно выбирать из набора функций наилучшую для этого браузера
2) Для большинства проектов такая сложность будет в очень малом количестве мест.
Для остальных - нужно заранее запастить валерьянкой, и быть готовым что тщательно вылизаный по перфомансу код будет устаревать за полгода.


Выводы из этого знания простые - не пытаться по дефолту перекладывать обработку больших данных с C#/C++/Java сервера на клиент.

wizzard0 July 4th, 2014
Я напомню, что у нас "по условию задачи" aka unique selling point - untrusted сервер ;-)

А так, конечно, да.

Насчет Java (на клиенте), Dalvik столь же непредсказуем, и медленнее JS во многих случаях ;)

dmih July 4th, 2014
6. А польза от node.js есть?

anonim_legion July 4th, 2014
В резюме вписать, например.

jakobz July 4th, 2014
Всё идет к тому, что в большом классе приложений большая часть кода - на клиенте. Плюс всякие компиляторы LESS или тот же server-side рендеринг в react - тоже на JS. Короче JS на сервере в любом случае будет, никак без него.

Дальше, если писать, скажем, контроллеры и доступ к БД на C#, а остальное - на JS, получаем что на C# большая часть кода - это гемморой про трансляцию чего-то в JSON и назад.

Короче вопрос не в том, есть ли польза от node.js, а в том, надо ли на сервере еще что-то кроме JS.

dmih July 4th, 2014
На IIS серверные компоненты на JS можно было писать уже лет 15, это ASP не к столу будет упомянуто. Всякие XHttpRequest/JS на клиенте уже тоже использовались вовсю. И никакой особой синергии от всего этого хозяйства не наблюдалось впомине, всё-таки, JS изначально достаточно слабый язык.

wizzard0 July 4th, 2014
+++, я согласен.

А какие, кстати, есть предложения по выбору языка, если хочется унифицировать codebase?

haXe? C#? Lua? Починить javascript backend у D? Opa?

(это вполне серьезный вопрос, мне любопытно)

dmih July 4th, 2014
Унифицировать с клиентом что ли? Если да, то сразу могу сказать, что я без понятия, более того, я не знаю, зачем это надо делать, т.к. роли очень разные. Я вижу несколько слабых аргументов.

- чтобы девелопер знал один язык" - ну это какой-то мрачный бред вообще;
- чтобы были общие либы - это простите зачем? что общего? реальный кейс какой? я знаю один реальный кейс - чтобы на клиент грузилось потом гигабайт ненужного года, см. bootstrap, jquery и так далее, это всего лишь основы, а своего такого можно понаписать еще в 100 раз больше;
- сериализация? лет 10-15 назад да, а в современных условиях очень слабый аргумент;
- общие типы данных (не классы, типы!) - могу согласиться, но опять же, всё равно 90% у всех будет на хешах, потому что это единственный метод удобных слабых связей, когда каждый уровень абстракции не знает всё о соседях в обе стороны до упора;
- что еще?

зато минусов - миллион; структура программы разная, паттерн проектирования разный, тесты разные, вопросы совместимости вообще разные по самые никуда, и так далее.
зачем?

wizzard0 July 4th, 2014
Долбаная жежешка жрет каменты. Где хваленый Express Lane? :/

Унифицировать бизнес-логику между разными клиентами (Android/iOS/Windows/Mac/web)
у нас client-side crypto, на сервере только шифрованные данные, а с ними особо не разгонишься.

(да, я в курсе про то, что javascript cryptography is bad, и браузер вообще не лучшая для этого платформа, но невозможность дать ссылку на что-нибудь не_юзеру_приложения это fail)

dmih July 4th, 2014
>>Унифицировать бизнес-логику между разными клиентами (Android/iOS/Windows/Mac/web)
если вдруг так случится, что унифицируется GUI или хотя бы браузеры, я думаю, экосистема образуется; сейчас же любое пободное программирование на 90% состоит из качественного секса с прослойкой-унификатором, и на другое сил уже не остается (ибо все прослойки тоже говно в силу специфики задач)

Client-side crypto не совсем до конца понятно зачем унификация. Криптопротоколы и их реализаци вроде как должны быть везде одинаковые и так.

justy_tylor July 4th, 2014
Общая бизнес-логика на клиенте это во многом logical UI. И его пока унифицировать нечем. Самый удобный вариант на сегодняшний день - генерировать самописным скриптом в соответствующие наборы (Java+XML говны, ObjC говны, HTML+CSS+JS и что-то там на десктопах). Заодно, в этот же скрипт сунуть верификацию, локализацию и прочие полезные моменты.

sorcerer_ July 5th, 2014
> ну это какой-то мрачный бред вообще

Не мрачный, Нод.жс родился именно и только из этого (хотя злые языки говорят, что у него нормальный эвент-бейзд сервер из одного треда и корутин, а не говно столетнее с процессами или тредами).

> чтобы были общие либы - это простите зачем? что общего? реальный кейс какой?

Реальный кейс прост как три копейки: код вместо разметки, код вместо контролов, код вместо всего. Т.е. клиент шлет серверу код, сервер шлет клиенту код.

> зато минусов - миллион; структура программы разная, паттерн проектирования разный, тесты разные, вопросы совместимости вообще разные по самые никуда, и так далее.
зачем?

Все там одинаковое. И структура и кейсы. Если подумать немного.
В нынешнем случае конечно разное все, ибо случай хуевый: ни секьюрити, ни мультитенанси нихера нет.

dmih July 4th, 2014
И вообще Microsoft, например, с интервалом в 3-4 года так надежно хоронит очередную свою технологих унификациии, что тем, кто знаком с этим процессом в перспективе, кажется, даже как-то неудобно стало об этом вспоминать; явно не дебилы, но попытки родить нерожаемое в исполнении ведущего софтварного вендора с гигантским опытом и ресурсами должны насторожить уже по-моему любого здорового человека с чувством истории.

dmih July 4th, 2014
Вообще так уж отвечая на вопрос, C# меня пожалуй устраивает в качестве базового языка, ну это не считая того факта, что последние годы 80% вещей я вообще на PHP пишу :) и меня тоже в принципе там всё устраивает (компонентные модели через eval и проч.)

murkt July 4th, 2014
> А какие, кстати, есть предложения по выбору языка, если хочется унифицировать codebase?

Clojure же, ClojureScript, все дела.

Из несбыточного

anonim_legion July 4th, 2014
Засунуть CLR в браузер.

Re: Из несбыточного

thedeemon July 5th, 2014
Silverlight был уже, мир праху его.

anonim_legion July 5th, 2014
В браузере была и ява в виде апплетов. Люди жаловались "память жрет, тормозит". ОК, теперь у меня есть яваскрипт, Chrome и Firefox, которые жрут память и тормозят.

thedeemon July 5th, 2014
Что занятно, причина неуспеха сервелата не связана с производительностью. Апплеты, флэш, сервелат - всех в первую очередь сгубила плохая интеграция в браузер, заточЁнность в ограниченный кусочек страницы.

wizzard0 July 5th, 2014
Т.е. NPAPI.

109 July 6th, 2014
когда появился сервелат, я очень обрадовался, потому что думал, что это дотнетовский код, который интегрируется в browser event system и пишет прямо в DOM. когда же выяснилось, что это просто аналог flash, стало понятно, что затея дурацкая.

jakobz July 4th, 2014
Язык сам не поменялся, но стал весьма быстрым. И это качественно поменяло картину.

Раньше веб-сервер на выходе имел html через http, а граница фронтенда и бекенда проходила где-то между контроллером и html-шаблоном. Был AJAX, но он опять же, как правило, дергал те же контроллеры, и обновлял куски страницы.

Сейчас веб-сервер - это билд-деплой-машина для JS-приложения, плюс JSON-сервисы для него. Фронтенд может начать работать на сервере: посмотреть URL, прикинуть какие сервисы сразу дернуть для страницы, отрендерить страницу; потом - прокинуться через html на клиента, и продолжить работать чисто дергая сервисы.

Такие замуты требуют JS на сервере. А на чем и как отдавать/забирать JSON от JS - это уже на вкус и цвет.

wizzard0 July 4th, 2014
Давай будем честными? Нода всё-таки гавнище.

Я, например, ожидаю, что MSFT допилит IE, чтобы он жрал хотя бы TypeScript напрямую, и оптимизированно его компилил.

Как по мне, польза от ноды только в том, что можно запустить React на сервере.

jakobz July 4th, 2014
Можно серверную часть RIA-приложений разбить на две самостоятельные части:
- фронтенд-каша-мала: раздает статику, билдует всякий LESS, роутинг обрабатывает, серверный рендеринг на JS, и всё остальное про http и html.
- сервисы - раздают JSON, про JS/CSS/HTML не знают вообще ничего

Так вот для первой части - нода, как это не печально, наверное лучше всего пойдет. Хотя я и не пробовал. Там и тулзы все, и все плюшки про отсутствие языкового барьера.

Вторую часть можно делать на чем угодно, но лучше - не на ноде. Впрочем, для типичных сайтиков и бекендов, эта часть весьма простая. Часто можно вообще напрямую в БД ходить, без всяких сишарпов.

nponeccop July 5th, 2014
node = v8 + libuv

Не понимаю как это может быть гавнищем.

Вебдев конечно на ноде делать не стоит.



wizzard0 July 5th, 2014
Stdlib ноды - гавнище.

См. https://medium.com/code-adventures/farewell-node-js-4ba9e7f3e52b > "Go versus Node"

nponeccop July 5th, 2014
Нда. Меня из его аргументов коснулось только отсутствие инструментов профайлинга. Остальное нерелевантно.

thedeemon July 5th, 2014
Взять, как Шабанов, Ur/Web и забыть про JS вообще.

nponeccop July 5th, 2014
Это до первой performance issue, т.е. подходит не всем

jakobz July 5th, 2014
Да, такое тоже можно. Вообще много чего делается в этом направлении - Om, Elm, Fay, Roy. Пока это всё очень сильно джедайское, но сам подход верный.

109 July 6th, 2014
слово гемморой пишется не так.

var json = JsonConvert.Serialize(data);

то же самое с десериализацией.

jakobz July 4th, 2014
Еще помножить на то, что производительность железки на клиенте может также отличатся минимум на порядок.

Впрочем, я смотрю на IE8: юзабельно там - сойдет везде.

wizzard0 July 4th, 2014
Нет, IE это хуйня, можно ориентироваться на 10+, больше всего проблем доставляет Android.

Хотя надо отметить, что у разных сайтов аудитория очень и очень различается...

Edited at 2014-07-04 06:27 pm (UTC)

jakobz July 4th, 2014
Ну, у меня внутреннее приложение, и прилично товарищей с IE7 заходит. Я хз, троллят они что-ли специально :)

kurumpa July 5th, 2014
А что андроид? Хром мобайл таки сильно проблем создает? Или не у всех хром?

mr_aleph July 5th, 2014
> (Я не знаю, что делать с этим знанием)

баги надо файлить с этим знанием.

  • 1
?

Log in

No account? Create an account