Хабрахабр

Почему я не верю микробенчмаркам

Скриншот с сайта с микробенчмарками"/>
Думаю, что одного этого скриншота реально существующего замера производительности хватит, чтобы донести смысл статьи, но, если читателю интересны мои мысли на этот счет, то добро пожаловать. <img src="http://orion-int.ru/wp-content/uploads/2018/12/pochemu-ya-ne-veryu-mikrobenchmarkam.png" alt="typescript работает быстрее javascript и занимает меньше памяти.

Мы следим за скоростью даже там, где эта скорость не очень-то и важна. Программисты помешаны на скорости исполнения программ. Даже не до конца понимая, что слова «скорость» или «перформанс» в действительности означают в каждом конкретном случае. Иногда вопреки здравому смыслу и логике. Мы все равно хотим самое быстрое железо, самый быстрый язык и самый легковесный фреймворк. 

Что ты сам способен написать правильный бенчмарк, знаешь, как работает тот или иной рантайм, ненавидишь оптимизацию скорости просто ради оптимизации скорости и знаешь толк в железе. Охотно верю, что ты, username, не такой. Проверял. Но людей из предыдущего параграфа больше.

Увидев пример на картинке выше, я сначала поперхнулся кофе…
– Как может typescript работать быстрее, чем javascript, и при этом кушать в несколько раз меньше памяти?!
– Никак!

То есть нельзя нигде или почти нигде запустить typescript. Typescript  не имеет собственного рантайма. В данном случае в качестве такого рантайма выступила node v11. Нужно сначала скомпилировать его в javascript, который потом запустить в рантайме, который этот самый javascript понимает. По счастливому совпадению, на том же рантайме бежит и пример на javascript. 
Вместо сравнения языков мы получаем микросоревнование по спортивному программированию. 3434.

→ Код на typescript
→ Код на javascript

Конечно, здесь можно притянуть за уши аргумент о том, что  typescript заставляет писать «правильный код». Получается, время выполнения, потребление памяти и прочие характеристики критично зависят от того, кто и как этот проверочный код писал. Но никто не помешает скомпилировать typescript в javascript, да и мест с оптимизациями я тоже не увидел.

Solid, ООП и ФП здесь и не пахнет. Кстати, давно ли вы видели, чтобы кто-то писал подобный код, и он проходил ревью? Потому что у него задача другая. Код написан явно в процедурном стиле. И неизвестно, как рефакторинг повлияет на производительность. Поймите правильно, код хоть и решает задачу, но требует рефакторинга перед продакшном. Но это уже, наверное, придирка.

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

Думаю, что неправильно. Как думаете, насколько правильно делать вывод о том, что Swift быстрее Go? Достаточно посмотреть, что две реализации на Rust (2 и 6 строка) по времени отличаются в 2 раза.

Если сравнение typescript и javascript воспринимается как шутка, то в случае других языков проблема уже не так очевидна. И здесь проблема выглядит уже серьезнее. Скриншот. А вы стали ли бы разбираться, в чем дело, если бы увидели такой отчет?
Сравнение go и swift.  Выглядит так, что swift быстрее

Получается, что код бенчмарков нужно пристально проверять.

Думаю, что таких инженеров исчезающе мало. Вопрос: Когда вы последний раз видели человека, который лезет перепроверять, как написан код бенчмарков сразу после того, как увидел стандартные красивые графики производительности?
Я таких встречаю очень редко.

И, кстати, формируется общественное мнение.
Вот здесь можно сравнить производительность основных фреймворков на javascript.
<img src="https://habrastorage.org/webt/oz/nt/cz/ozntczbno15gqywrcr5i7fdjlj0.png" alt="результаты сравнение js фреймворков. С другой стороны, перед глазами много примеров, когда на основании подобных тестов делается вывод о производительности и легковесности технологии. Я – нет.
На этом все. Скриншот"/>
Вы все еще доверяете результатам? Мастерство программиста по-прежнему сильно влияет на производительность программы.  Но есть и хорошие новости.

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

S.:
Пост написан как ответ на поспешные сравнения и выводы о произвоительности в будущем. P. Конечно, все выводы и доводы из статьи можно приводить и без этого примера, но с цифрами и конкретикой оно веселее и нагляднее.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть