JavaScript, который мы пишем, не всегда исполняется, как мы думаем. Виртуальные машины, исполняющие его, делают многое, чтобы он работал быстрее. Но они не всесильны, и чтобы сделать код действительно быстрым, нужно знать их особенности и как все работает под капотом.
Поговорим об этих особенностях, что может служить причиной потери производительности, как это диагностировать и как делать код действительно быстрым. Доклад базируется на опыте, полученном в ходе работы над такими проектами как basis.js (весьма быстрый фреймворк для SPA), CSSO (минификатор CSS, который из медленного стал один из самых быстрых), CSSTree (самый быстрый детальный CSS парсер) и других.
CSSO – инструмент для минификации CSS, который не так давно вернулся к активной разработке. Помимо исправленных багов и новых фич, он значительно ускорился и стал одним из самых быстрых структурных минификаторов CSS.
Доклад о том как это достигалось, оптимизациях, деоптимизациях, структурах данных и подходах.
Holy.js, Санкт-Петербург, 5 июня 2016
Видео: https://www.youtube.com/watch?v=8o3gKKD_J4A
Как сделать ваш JavaScript быстрее / Роман Дворнов (Авито)Ontico
JavaScript, который мы пишем, не всегда исполняется, как мы думаем. Виртуальные машины, исполняющие его, делают многое, чтобы он работал быстрее. Но они не всесильны, и чтобы сделать код действительно быстрым, нужно знать их особенности и как все работает под капотом.
Поговорим об этих особенностях, что может служить причиной потери производительности, как это диагностировать и как делать код действительно быстрым. Доклад базируется на опыте, полученном в ходе работы над такими проектами как basis.js (весьма быстрый фреймворк для SPA), CSSO (минификатор CSS, который из медленного стал один из самых быстрых), CSSTree (самый быстрый детальный CSS парсер) и других.
Ангелы и демоны многопоточного программирования / Алексей Федоров (Одноклассн...Ontico
Современные процессоры имеют на борту по нескольку вычислительных ядер, позволяющих запускать задачи на них параллельно. И, казалось бы, вот оно — счастье: бей большие задачи на куски, запускай эти куски параллельно на разных ядрах и радуйся.
Но не все так просто. Для того чтобы одновременный доступ к общим данным выполнялся корректно, современные системы используют разные примитивы синхронизации. В основе одних лежат блокировки (locks), в основе других — операции типа сравнение-с-обменом (compare-and-swap). Однако и у тех и у других есть свои слабые места. О них мы и поговорим.
Из доклада вы узнаете, чем блокирующие алгоритмы отличаются от неблокирующих, и какими достоинствами и недостатками обладает каждый из этих классов. Кроме того, будут показаны различные подводные камни тех и других решений: Deadlock, Livelock, Starvation, Mutable vs Immutable hype.
Производительность запросов в PostgreSQL - шаг за шагом / Илья Космодемьянски...Ontico
Вы взяли ваш любимый фреймворк™ и быстро запустили крутой проект, который раскручивается, приносит деньги и требует быстрого развития, чтобы оставить конкурентов далеко позади.
В один далеко не прекрасный момент вы понимаете, что корень всех зол - медленное время ответа базы данных, а ваш админ зло смотрит на разработчиков красными от бессонницы глазами и ругается на безумные запросы, которые генерирует ORM. Тот самый ORM, который позволил вам так быстро запустить ваш замечательный проект.
Знакомо? Тогда вам будет интересно послушать, как заставить вашу базу данных работать прямо сейчас. А именно:
- какое место в общей производительности базы данных занимает оптимизация запросов?
- когда прекращать “крутить гайки” и заниматься медленными запросами?
- что такое медленный запрос и когда их надо начинать оптимизировать?
- как оптимизировать?
- EXPLAIN, EXPLAIN ANALYZE - как читать и на что обращать внимание?
- как работает оптимизатор запросов PostgreSQL и где могут быть узкие места?
- для чего нужны и для чего не нужны индексы, методики индексирования, и как быть уверенным, что ваш индекс правильно используется?
- какие запросы не будут работать быстро никогда, и как с этим жить?
- ошибается ли оптимизатор и, если да, то почему и как его в таком случае призвать к порядку?
Функциональное тестирование высоконагруженных проектов / Илья Пастушков (2ГИС)Ontico
В докладе я расскажу о следующем:
+ почему тема доклада не оговорка, а абсолютно реальная вещь;
+ что можно извлечь из результатов теста помимо «да/нет»;
+ в каких случаях «количество» = «качество»;
+ когда «один в поле не воин»;
+ немного о том, зачем тестировщику нужна матстатистика;
+ как избежать случайностей в результатах;
+ «буря в стакане» или масштабируем highload в docker/openvz;
+ почему фиксация запросов в тестах приводит к фиксации сервиса на продакшене;
+ а также всё вышеперечисленное на примерах наших проектов.
CSSO – инструмент для минификации CSS, который не так давно вернулся к активной разработке. Помимо исправленных багов и новых фич, он значительно ускорился и стал одним из самых быстрых структурных минификаторов CSS.
Доклад о том как это достигалось, оптимизациях, деоптимизациях, структурах данных и подходах.
Holy.js, Санкт-Петербург, 5 июня 2016
Видео: https://www.youtube.com/watch?v=8o3gKKD_J4A
Как сделать ваш JavaScript быстрее / Роман Дворнов (Авито)Ontico
JavaScript, который мы пишем, не всегда исполняется, как мы думаем. Виртуальные машины, исполняющие его, делают многое, чтобы он работал быстрее. Но они не всесильны, и чтобы сделать код действительно быстрым, нужно знать их особенности и как все работает под капотом.
Поговорим об этих особенностях, что может служить причиной потери производительности, как это диагностировать и как делать код действительно быстрым. Доклад базируется на опыте, полученном в ходе работы над такими проектами как basis.js (весьма быстрый фреймворк для SPA), CSSO (минификатор CSS, который из медленного стал один из самых быстрых), CSSTree (самый быстрый детальный CSS парсер) и других.
Ангелы и демоны многопоточного программирования / Алексей Федоров (Одноклассн...Ontico
Современные процессоры имеют на борту по нескольку вычислительных ядер, позволяющих запускать задачи на них параллельно. И, казалось бы, вот оно — счастье: бей большие задачи на куски, запускай эти куски параллельно на разных ядрах и радуйся.
Но не все так просто. Для того чтобы одновременный доступ к общим данным выполнялся корректно, современные системы используют разные примитивы синхронизации. В основе одних лежат блокировки (locks), в основе других — операции типа сравнение-с-обменом (compare-and-swap). Однако и у тех и у других есть свои слабые места. О них мы и поговорим.
Из доклада вы узнаете, чем блокирующие алгоритмы отличаются от неблокирующих, и какими достоинствами и недостатками обладает каждый из этих классов. Кроме того, будут показаны различные подводные камни тех и других решений: Deadlock, Livelock, Starvation, Mutable vs Immutable hype.
Производительность запросов в PostgreSQL - шаг за шагом / Илья Космодемьянски...Ontico
Вы взяли ваш любимый фреймворк™ и быстро запустили крутой проект, который раскручивается, приносит деньги и требует быстрого развития, чтобы оставить конкурентов далеко позади.
В один далеко не прекрасный момент вы понимаете, что корень всех зол - медленное время ответа базы данных, а ваш админ зло смотрит на разработчиков красными от бессонницы глазами и ругается на безумные запросы, которые генерирует ORM. Тот самый ORM, который позволил вам так быстро запустить ваш замечательный проект.
Знакомо? Тогда вам будет интересно послушать, как заставить вашу базу данных работать прямо сейчас. А именно:
- какое место в общей производительности базы данных занимает оптимизация запросов?
- когда прекращать “крутить гайки” и заниматься медленными запросами?
- что такое медленный запрос и когда их надо начинать оптимизировать?
- как оптимизировать?
- EXPLAIN, EXPLAIN ANALYZE - как читать и на что обращать внимание?
- как работает оптимизатор запросов PostgreSQL и где могут быть узкие места?
- для чего нужны и для чего не нужны индексы, методики индексирования, и как быть уверенным, что ваш индекс правильно используется?
- какие запросы не будут работать быстро никогда, и как с этим жить?
- ошибается ли оптимизатор и, если да, то почему и как его в таком случае призвать к порядку?
Функциональное тестирование высоконагруженных проектов / Илья Пастушков (2ГИС)Ontico
В докладе я расскажу о следующем:
+ почему тема доклада не оговорка, а абсолютно реальная вещь;
+ что можно извлечь из результатов теста помимо «да/нет»;
+ в каких случаях «количество» = «качество»;
+ когда «один в поле не воин»;
+ немного о том, зачем тестировщику нужна матстатистика;
+ как избежать случайностей в результатах;
+ «буря в стакане» или масштабируем highload в docker/openvz;
+ почему фиксация запросов в тестах приводит к фиксации сервиса на продакшене;
+ а также всё вышеперечисленное на примерах наших проектов.
Модульность и управляемая многопоточность встраиваемых С++ приложений - трудн...corehard_by
- Организация программной системы как совокупности модулей, интерфейсов и управляющих систем.
- Многопоточность - предпосылки для использования и объективная необходимость.
- Организация многопоточности при проектировании алгоритмов, основанных на событиях.
Основы индексирования и расширенные возможности EXPLAIN в MySQL / Василий Лук...Ontico
Индексы
- типы индексов;
- типы доступа к таблице;
- составные индексы (когда они работают);
- получение информации об индексе (show index; - описание формата);
- примеры с поиском по нескольким полям и сортировкой: какие индексы будут использоваться, а какие нет;
- что делать в случае нескольких условий по диапазону;
- как сервер выбирает индекс, который будет использован;
- директивы use/force/ignore index.
EXPLAIN
- как работает оптимизатор запросов;
- недостатки explain;
- explain extended;
- получение sql запроса, восстановленного из плана;
- формат выводимой explain информации:
-- что означает каждый столбец;
-- какие значения принимает (для extra только самые часто встречающиеся);
-- на что обратить внимание с точки зрения производительности;
-- как правильно читать план-разбор сложного примера с join-ами, подзапросами (обычными и from) и union-ами;
- новые возможности explain в последних версиях.
Практические примеры (исходный запрос, план, оптимизация, итоговый план) для разных случаев оптимизации:
1. добавление индексов;
2. эквивалентное изменение запроса: or --> union, подзапрос --> join;
3. разбиение запроса на несколько с сохранением промежуточных данных во временной таблице;
4. изменение структуры данных;
5. использование пользовательских переменных.
WebGL многими воспринимается как API для "быстрого" рисования. Но на практике нередко случается, что решение на WebGL выходит медленным, иногда даже медленнее решений на других API.
В этом докладе мы попробуем взглянуть на проблемы производительности, встречающиеся в работе с WebGL, и их решения на примере движка Панорам Яндекс.Карт.
Использование юнит-тестов для повышения качества разработкиvictor-yastrebov
В докладе рассмотрены подходы к созданию надежных юнит-тестов, которые просты в поддержке и модернизации, а также принципы создания кода пригодного для покрытия автотестами. Приведены два способа внедрения зависимости: с использованием конструктора тестируемого объекта, а также с использованием подхода "выделить и переопределить". Каждый из способов разобран на примере, демонстрирующем особенности его реализации и применения. Приведен ряд практических советов, нацеленных на создание надежных юнит-тестов. Использование на практике приведенных подходов и принципов позволяет упростить процесс поддержки и модификации существующего кода, а также дает уверенность в надежности работы добавляемого нового функционала. В конечном итоге это приводит к повышению качества разрабатываемого продукта.
Отладка производительности приложения на Erlang / Максим Лапшин (Erlyvideo)Ontico
Байткод эрланга выполняет очень хорошо отлаженная виртуальная машина BEAM, которая превосходно работает даже на современных 72-х и более ядерных компьютерах.
Ключевая возможность эрланга в том, чтобы использовать все ядра в одном приложении, т.е. иметь в памяти одни и те же данные и обеспечивать к ним доступ без запуска кучи экземпляров одного и того же приложения по количеству ядер.
С ростом обрабатываемого трафика данных начинают возникать проблемы с многоядерным доступом к данным, возникают бутылочные горлышки и более низкоуровневые проблемы синхронизации.
В этом докладе будет рассказано, какие есть методы поиска, анализа, замера и устранения различных проблем, связанных с многотредностью: синглтонные процессы, простаивания на мьютексах и т.п.
Одноклассники состоят из тысяч серверов, большая часть которых участвует в онлайн обработке запросов пользователей. Каждый из этих серверов владеет только частью данных или логики. Эти части в социальной сети изолировать друг от друга невозможно, поэтому между серверами происходит много сетевого взаимодействия, разнообразного и большого по объему. Таким образом, Одноклассники - это одна из самых больших, сложных и нагруженных распределенных систем в мире.
В этом докладе я расскажу об опыте построения отказоустойчивых распределенных систем на Java, основных ошибках и отказах, приемах их тестирования и диагностики. Также поговорим об авариях в распределенных системах и методах их предупреждения.
Производительность Unity3D: подводные камни / Алексей Чубарь (BIT.GAMES)Ontico
Unity3D - это внушительный набор средств для кроссплатформенной разработки игр и 3D-приложений. Однако ряд его особенностей может привести к внезапному падению производительности продукта на мобильных платформах.
Где же прячутся подводные камни? Как обеспечить оптимальный user experience на старом смартфоне? Каких "граблей" стоит избегать при написании кода и подготовке графики? Рассмотрим на примере RPG "Гильдия Героев" для Android и iOS.
Multithreading in java past and actualYevgen Levik
In this talk I’d like to give you an overview of java.util.concurrent package and represent useful Java concurrency tools. I’ll cover the core functionality and the state-of-the-art API (Executors, Accumulators, StampedLock etc).
Simple examples in github (https://github.com/levik666/OverviewInJavaUtilConcurrent)
Из презентации вы узнаете:
— как мы пришли к Go, оставив идею использования Node.js, Scala или Rust;
— про первый сервис, который мы написали на Go и запустили в продакшен;
— про ошибки, с которыми сталкивались под нагрузкой;
— про оптимизации, которые мы сделали и еще планируем сделать;
— про тестирование и предотвращение тестирования на продакшене (в частности, websocket'ов).
Очередной скучный доклад про логгированиеPython Meetup
Стас Рудаков, компания СООО "Гейм Стрим"/Wargaming.net
Значение логов очень часто недооценивается, а зря. Доклад с оживленным диспутом со всеми участниками митапа, чтобы разобраться: как, куда и зачем писать логи. Помимо этого затронут вопрос, как из логов выжать больше информации.
"Fault tolerant workflow orchestration on PHP", Anton TsitouFwdays
Workflow orchestration systems.
About Temporal.IO (Cadence, AWS SWF).
Integrating Temporal to RoadRunner and PHP.
Overview of PHP SDK for durable workflow orchestration.
Рано или поздно возникает необходимость в собственных инструментах по разным причинам: либо не хватает готовых, либо есть какая-то особенность в проекте. Разработка инструментов, работающих в браузере, является непростой задачей. Самое сложное — чтобы они умели работать удаленно, вне страницы. Это многих пугает — нужно много сделать и во многом разобраться. Но если большая часть проблем уже решена, и можно сосредоточиться лишь на основной функции инструмента? Что если такие инструменты смогут работать в произвольном WebView, будь оно встроено в браузер, редактор или другое приложение на любом устройстве? Доклад про удалённые инструменты: какие есть сложности и как их обойти, как перестать бояться и начать делать инструменты под свои задачи и технологический стек.
Я занимаюсь CSSO. В ходе работы над ним мне пришлось погрузиться в процесс парсинга CSS. В результате парсер (тот, что в CSSO) был не раз переписан. Пришло время сделать его отдельным инструментом.
Новый быстрый детальный парсер CSS, его AST, области применения и кое-что ещё.
Модульность и управляемая многопоточность встраиваемых С++ приложений - трудн...corehard_by
- Организация программной системы как совокупности модулей, интерфейсов и управляющих систем.
- Многопоточность - предпосылки для использования и объективная необходимость.
- Организация многопоточности при проектировании алгоритмов, основанных на событиях.
Основы индексирования и расширенные возможности EXPLAIN в MySQL / Василий Лук...Ontico
Индексы
- типы индексов;
- типы доступа к таблице;
- составные индексы (когда они работают);
- получение информации об индексе (show index; - описание формата);
- примеры с поиском по нескольким полям и сортировкой: какие индексы будут использоваться, а какие нет;
- что делать в случае нескольких условий по диапазону;
- как сервер выбирает индекс, который будет использован;
- директивы use/force/ignore index.
EXPLAIN
- как работает оптимизатор запросов;
- недостатки explain;
- explain extended;
- получение sql запроса, восстановленного из плана;
- формат выводимой explain информации:
-- что означает каждый столбец;
-- какие значения принимает (для extra только самые часто встречающиеся);
-- на что обратить внимание с точки зрения производительности;
-- как правильно читать план-разбор сложного примера с join-ами, подзапросами (обычными и from) и union-ами;
- новые возможности explain в последних версиях.
Практические примеры (исходный запрос, план, оптимизация, итоговый план) для разных случаев оптимизации:
1. добавление индексов;
2. эквивалентное изменение запроса: or --> union, подзапрос --> join;
3. разбиение запроса на несколько с сохранением промежуточных данных во временной таблице;
4. изменение структуры данных;
5. использование пользовательских переменных.
WebGL многими воспринимается как API для "быстрого" рисования. Но на практике нередко случается, что решение на WebGL выходит медленным, иногда даже медленнее решений на других API.
В этом докладе мы попробуем взглянуть на проблемы производительности, встречающиеся в работе с WebGL, и их решения на примере движка Панорам Яндекс.Карт.
Использование юнит-тестов для повышения качества разработкиvictor-yastrebov
В докладе рассмотрены подходы к созданию надежных юнит-тестов, которые просты в поддержке и модернизации, а также принципы создания кода пригодного для покрытия автотестами. Приведены два способа внедрения зависимости: с использованием конструктора тестируемого объекта, а также с использованием подхода "выделить и переопределить". Каждый из способов разобран на примере, демонстрирующем особенности его реализации и применения. Приведен ряд практических советов, нацеленных на создание надежных юнит-тестов. Использование на практике приведенных подходов и принципов позволяет упростить процесс поддержки и модификации существующего кода, а также дает уверенность в надежности работы добавляемого нового функционала. В конечном итоге это приводит к повышению качества разрабатываемого продукта.
Отладка производительности приложения на Erlang / Максим Лапшин (Erlyvideo)Ontico
Байткод эрланга выполняет очень хорошо отлаженная виртуальная машина BEAM, которая превосходно работает даже на современных 72-х и более ядерных компьютерах.
Ключевая возможность эрланга в том, чтобы использовать все ядра в одном приложении, т.е. иметь в памяти одни и те же данные и обеспечивать к ним доступ без запуска кучи экземпляров одного и того же приложения по количеству ядер.
С ростом обрабатываемого трафика данных начинают возникать проблемы с многоядерным доступом к данным, возникают бутылочные горлышки и более низкоуровневые проблемы синхронизации.
В этом докладе будет рассказано, какие есть методы поиска, анализа, замера и устранения различных проблем, связанных с многотредностью: синглтонные процессы, простаивания на мьютексах и т.п.
Одноклассники состоят из тысяч серверов, большая часть которых участвует в онлайн обработке запросов пользователей. Каждый из этих серверов владеет только частью данных или логики. Эти части в социальной сети изолировать друг от друга невозможно, поэтому между серверами происходит много сетевого взаимодействия, разнообразного и большого по объему. Таким образом, Одноклассники - это одна из самых больших, сложных и нагруженных распределенных систем в мире.
В этом докладе я расскажу об опыте построения отказоустойчивых распределенных систем на Java, основных ошибках и отказах, приемах их тестирования и диагностики. Также поговорим об авариях в распределенных системах и методах их предупреждения.
Производительность Unity3D: подводные камни / Алексей Чубарь (BIT.GAMES)Ontico
Unity3D - это внушительный набор средств для кроссплатформенной разработки игр и 3D-приложений. Однако ряд его особенностей может привести к внезапному падению производительности продукта на мобильных платформах.
Где же прячутся подводные камни? Как обеспечить оптимальный user experience на старом смартфоне? Каких "граблей" стоит избегать при написании кода и подготовке графики? Рассмотрим на примере RPG "Гильдия Героев" для Android и iOS.
Multithreading in java past and actualYevgen Levik
In this talk I’d like to give you an overview of java.util.concurrent package and represent useful Java concurrency tools. I’ll cover the core functionality and the state-of-the-art API (Executors, Accumulators, StampedLock etc).
Simple examples in github (https://github.com/levik666/OverviewInJavaUtilConcurrent)
Из презентации вы узнаете:
— как мы пришли к Go, оставив идею использования Node.js, Scala или Rust;
— про первый сервис, который мы написали на Go и запустили в продакшен;
— про ошибки, с которыми сталкивались под нагрузкой;
— про оптимизации, которые мы сделали и еще планируем сделать;
— про тестирование и предотвращение тестирования на продакшене (в частности, websocket'ов).
Очередной скучный доклад про логгированиеPython Meetup
Стас Рудаков, компания СООО "Гейм Стрим"/Wargaming.net
Значение логов очень часто недооценивается, а зря. Доклад с оживленным диспутом со всеми участниками митапа, чтобы разобраться: как, куда и зачем писать логи. Помимо этого затронут вопрос, как из логов выжать больше информации.
"Fault tolerant workflow orchestration on PHP", Anton TsitouFwdays
Workflow orchestration systems.
About Temporal.IO (Cadence, AWS SWF).
Integrating Temporal to RoadRunner and PHP.
Overview of PHP SDK for durable workflow orchestration.
Рано или поздно возникает необходимость в собственных инструментах по разным причинам: либо не хватает готовых, либо есть какая-то особенность в проекте. Разработка инструментов, работающих в браузере, является непростой задачей. Самое сложное — чтобы они умели работать удаленно, вне страницы. Это многих пугает — нужно много сделать и во многом разобраться. Но если большая часть проблем уже решена, и можно сосредоточиться лишь на основной функции инструмента? Что если такие инструменты смогут работать в произвольном WebView, будь оно встроено в браузер, редактор или другое приложение на любом устройстве? Доклад про удалённые инструменты: какие есть сложности и как их обойти, как перестать бояться и начать делать инструменты под свои задачи и технологический стек.
Я занимаюсь CSSO. В ходе работы над ним мне пришлось погрузиться в процесс парсинга CSS. В результате парсер (тот, что в CSSO) был не раз переписан. Пришло время сделать его отдельным инструментом.
Новый быстрый детальный парсер CSS, его AST, области применения и кое-что ещё.
Шаблонизация основанная на работе с DOM становится трендом: React, Ractive, Basis.js уже используют этот подход, другие идут в эту сторону. Главным преимуществом подхода считается скорость, но оно далеко не единственное!
В докладе немного рассказано о возможностях, что дает DOM подход.
Инструменты разные нужны, инструменты разные важныRoman Dvornov
В мире фронтенда уже существует большое количество инструментов: как браузерных, так и консольных. Но достаточно ли этих инструментов? Мне кажется, что нет. Веб-приложения становятся все больше и сложнее, и многое остается вне нашего поля зрения. Потому фреймворки и приложения должны предоставлять дополнительные инструменты, упрощающие разработку и улучшающие понимание того, что же происходит у них там — «под капотом». В ходе доклада я расскажу о таких инструментах: какими они могут быть, какие задачи могут решать, что необходимо для их создания.
CodeFest, Новосибирск, 28 марта 2015
http://www.youtube.com/watch?v=HMTc3DERw5c
Talk is about CSS minification problem, how minifiers work, new advanced optimisations, how minification influences on performance, CSSO reborn and future plans.
В последнее время во фронтенде появляется столько нового и внедряется настолько быстро, что не все успевают осознать последствия. Хорошо это или плохо? Рассмотрим некоторые новинки с точки зрения «за», а главное – «против».
Конференция FrontTalks, Екатеринбург, 19 сентября
Видео: https://vimeo.com/107694664
С ростом количества CSS на клиенте, разработчики озаботились его минимизацией: сначала простыми заменами, а потом и структурной оптимизацией. Первым иструментом, где появилась такая оптимизация, был CSSO и он оставался лучшим, пока не был заброшен. Не так давно он снова вернулся к жизни. Принципы работы CSSO, новые идеи оптимизаций и изменения в последних релизах от нового мейнтейнера проекта.
Видео: https://www.youtube.com/watch?v=IUtbbN9aevU
Веб-приложения становятся все больше и сложнее, так что многое остается вне нашего поля зрения. Поэтому фреймворки и приложения должны предоставлять дополнительные инструменты, упрощающие разработку и понимание того, что же происходит у них там — «под капотом». В ходе доклада я расскажу о таких инструментах: какими они могут быть, какие задачи решать, что необходимо для их создания.
SPA Meetup, 28 февраля 2015, Москва, Авито
Не бойся, это всего лишь данные... просто их многоRoman Dvornov
За последние 15 лет веб сильно изменился и ускорился. Но большинство по-прежнему боится большого количества данных и сложной логики на клиенте. Потому что "тормозит".
Я хочу сломать стереотипы и показать, как начать делать крутые штуки на client-side. Тысячи и сотни тысяч объектов, разные типы, зависимые вычисляемые свойства, агрегация, множество вариантов отображения. Все это в вашем браузере. Без тормозов, регистраций, смс.
Видео этого доклада на конференции DUMP, Екатеринбург, 14 марта 2014: https://vimeo.com/90836493
Не так давно случился значимый прецедент в истории W3C. Были приняты две конфликтующие спецификации, решающие одну проблему: Touch Events и Pointer Events. Почему так получилось, что это значит и что с этим делать?
Конференция WSD, Минск, 26 октября 2014
Видео: http://www.youtube.com/watch?v=dQoz5KZUH2M
Mobile Frontend Meetup, Москва, 4 июля 2015
"Basis.js - Production Ready SPA Framework" Сергей Мелюков (Avito)AvitoTech
Basis.js - это мощный фреймворк для создания полноценных SPA приложений. Он давно и активно используется в production, в том числе и в Avito. Цель доклада - рассказать об основных возможностях фреймворка и побудить слушателей попробовать данный фреймворк при создании SPA-приложений.
С ростом кодовой базы становится все более очевидной необходимость использования компонентного подхода, когда каждая логическая часть обособлена. Если говорить про JavaScript, то в нем есть области видимости, опираясь на которые можно соорудить изолированные компоненты. Но в CSS нет подобных механизмов, поэтому и придумываются Shadow DOM (Web Components) и различные методики вроде БЭМ.
Но что если взглянуть на проблему под другим углом? Адаптируя подходы, что уже используются для других задач, можно получить куда больше выгоды, чем просто изолированные стили!
FrontendConf, Москва, 21 мая 2015
WSD, Санкт-Петербург, 20 июня 2015
Запись трансляции: https://youtu.be/V7bnSOwuO4M?t=1h31m33s
Мы в Avito не так давно начали использовать Golang, но он уже успел занять важное место в различных частях проекта. В докладе мы расскажем о том, какие задачи нам помогает решать Go, почему выбор пал именно на этот язык, с какими подводными камнями мы столкнулись, и как их обходили. В частности поговорим про:
• Сервисы. Как мы начали использовать Go для разработки микросервисов, как это сказалось на их поддержке, а также отдельно расскажем про “шаблон сервиса”, который мы используем.
• Поиск. Как мы с помощью Go мы реализовали RtIndexer для обновления Sphinx Rt индексов в кластере из множества машин (поиск по активным объявлениям), который устойчиво работает с отставанием не более 10 секунд при нагрузке до 1000 rps.
• Автоматизацию тестирования. Как мы пишем тестовые сервисы и API на Go. Подробней остановимся на использовании общих моделей тел запросов и ответов для отправки и получения, использовании горутин как воркеров для обработки очереди.
PostgreSQL worst practices, version FOSDEM PGDay 2017 by Ilya KosmodemianskyPostgreSQL-Consulting
This talk is prepared as a bunch of slides, where each slide describes a really bad way people can screw up their PostgreSQL database and provides a weight - how frequently I saw that kind of problem. Right before the talk I will reshuffle the deck to draw ten random slides and explain you why such practices are bad and how to avoid running into them.
Современный статический анализ кода: что умеет он, чего не умели линтерыcorehard_by
Статический анализ появился почти 40 лет назад. В своём докладе мы хотим показать, чему за это время научились статические анализаторы. Мы рассмотрим различные методики анализа, как они появлялись и какие ошибки можно найти с помощью них. Посмотрим на примеры ошибок, найденных PVS-Studio в Open Source проектах. Поговорим о том, чем статический анализатор отличается от "линтеров" и некоторых других инструментов, а также какие проблемы решает современный статический анализатор C++ кода, помимо собственно анализа кода.
Павел Беликов
@PVS-Studio, Тула, Россия
Presentation from https://heisenbug-piter.ru/en/talks/2018/spb/kkw6oivsoywayacggksmk/
Once upon a time, we got a requirement to finish all testing in 2 days despite the number of tests to run. That number grew, and grew, and grew, and now there are tens of millions of them. So this is a story about building a dam against the never-ending flood which turned out to be not that scary. You are very welcome to join and see it for yourself.
Статический анализ кода: борьба с удорожанием ошибокAndrey Karpov
Нет смысла говорить, что "надо писать код без ошибок". Ошибки были, есть и будут. Все хорошо понимают, что ошибки следует исправлять. Люди забывают, что ошибка должна быть исправлена с минимальными временными и денежными затратами!
C++ CoreHard Autumn 2018. Заглядываем под капот «Поясов по C++» - Илья Шишковcorehard_by
Вот уже более двух лет мы создаём онлайн-специализацию по С++ на платформе Coursera. Её цель — обучить языку C++ с нуля до уровня, достаточного для решения практических задач, с которыми приходилось сталкиваться авторам в своей практике. В своём докладе я расскажу, как мы создаём наши онлайн-курсы, и уделю особое внимание техническим проблемам, которые нам пришлось решить в процессе создания автоматической системы проверки программ студентов.
Зачем тестировать? Тестирование в интерпретаторе и доктесты. Модуль unittest. Пакет py.test - на порядок лучше. Тестирование свойств и пакет hypothesis.
OpenSource SQL Databases Enter Millions Queries per Second EraSveta Smirnova
Доклад прочитан на Highload++ 8 ноября 2016 года совместно с Фёдором Сигаевым и Анастасией Распопиной. Подготовка слайдов совместно с Александром Коротковым.
Open Source SQL-базы данных вступили в эру миллионов запросов в секунду / Фед...Ontico
Широко распространено мнение, что SQL СУБД обречены быть медлительными и неповоротливыми, поскольку несут груз совместимости с предыдущими версиями. Это расхожее мнение широко эксплуатируется маркетингом NoSQL СУБД. Однако, это не всегда действительно так.
Разработка в Open Source сообществе позволяет продукту развиваться достаточно гибко, чтобы отвечать требованиям времени. В MySQL и PostgreSQL – самых популярных Open Source СУБД – недавно были проведены оптимизации для работы на больших серверах, что позволило им выполнять более миллиона SQL-запросов в секунду на одном экземпляре БД.
В данном докладе будут рассмотрены конкретные оптимизации, которые позволили добиться таких результатов, которые раньше могли бы показаться фантастическими. И можно сказать, что Open Source СУБД вошли в эру миллионов запросов в секунду.
Евгений Рыжков, Андрей Карпов Как потратить 10 лет на разработку анализатора ...Platonov Sergey
Кто-то верно подметил, что разработчики статических анализатора часто сталкиваются с "проблемой айсберга". Им сложно объяснить разработчикам, почему сложно написать и развивать статические анализаторы кода. Дело в том, что сторонние наблюдатели видят только вершину всего процесса, так как им доступен для изучения только простой интерфейс, который предоставляют анализаторы для взаимодействия с миром. Это ведь не графический редактор с сотнями кнопок и рычажков. В результате и возникает ощущение, что раз прост интерфейс взаимодействия, то и прост продукт. На самом деле статические анализаторы кода — это сложные программы, в которых живут и взаимодействуют разнообразнейшие методы поиска дефектов. В них реализуется множество экспертные системы, выдающие заключения о коде на основе как точных, так и эмпирических алгоритмах. В парном докладе, основатели анализатора PVS-Studio расскажут о том, как незаметно потратить 10 лет, чтобы написать хороший анализатор. Дьявол кроется в деталях!
Юлия Ковалёва. Fscheck — альтернативный путь для unit тестовMskDotNet Community
Как помочь тестам находить баги? Что лучше: каждый новый запуск на новом наборе данных или же стабильность? Как сделать тестовые данные эффективными?
В докладе рассматривается Property based подход для написания unit-тестов.
На реальных примерах будет показано то, какими возможностями обладает FsCheck в связке с C#, какие есть плюсы и минусы у данного инструмента и стоит ли тратить время на его изучение.
Тестировать регресс верстки скриншотами модно, этим никого не удивишь. Мы давно хотели внедрить этот вид тестирования у себя. Все время смущали вопросы простоты поддержки и применения, но в большей степени вопрос пропускной способности решений (производительности). Хотелось решения, простого в использовании и быстрого в работе. Готовые решения не подошли, и мы взялись делать свое.
В докладе расскажем, что из этого вышло, какие задачи решали и как мы добились того, чтобы тестирование скриншотами практически не влияло на общее время прохождения тестов.
Видео: https://youtu.be/ULwdj_Vr_WA
Когда проект делает один разработчик — все просто. Когда над ним работает небольшая команда, можно синхронизироваться и договориться. А вот когда проектов (сайтов и приложений) становится много, и над ними трудится множество команд с перекрестной функциональностью и смежными зонами ответственности, все становится сложным и запутанным.
Я расскажу о своем виденье архитектуры фронтенда, какой она должна быть, чтобы обеспечить её масштабируемость. На основе своего опыта и проблем, с которыми сталкиваются большие проекты.
Видео: https://www.youtube.com/watch?list=PLknJ4Vr6efQFtZmsXmGG64Rz_PHrcXCBL&v=z9y6PNC2FL0
Большинство считает CSS чем-то простым и не заслуживающим внимания. Но за мнимой простотой кроется большая сложность и огромный пласт проблем, не имеющих пока решения. Современный CSS с его объёмами, новыми фичами, разной поддержкой и багами браузеров, уже почти не поддается анализу человеком. Для этого появляются программы, которые разбирают CSS на атомы, анализируют и помогают сделать его лучше. Как к этому прийти, где мы сейчас и что ещё предстоит сделать.
Rempl – крутая платформа для крутых инструментовRoman Dvornov
Фронтенд усложняется с каждым днем, и уже не представить жизнь разработчика без инструментов. Инструментов становится все больше, но нельзя сказать, что их достаточно. Если у вас собственный стек или технологическое решение, вам рано или поздно потребуется сделать свой инструмент. Это не так просто! Особенно если вы захотите интегрировать его интерфейс в браузерные Developer Tools, IDE, редакторы или открыть их на другом устройстве. Добавьте сюда проблему версионирования и другие сложности, и вам покажется, что задача неподъемная.
Но есть хорошая новость! Большинство из этих проблем решает Rempl — платформа для создания и использования удаленных инструментов (на самом деле не только инструментов). Сделаем небольшой обзор Rempl: что это, зачем нужно, какие проблемы решает. А также посмотрим примеры готовых решений, построенных на Rempl.
CodeFest, Новосибирск, 2017
CSSO — инструмент для минификации CSS, который недавно вернулся к активной разработке. Зачем?
Дело в том, что минификация CSS — задача сложная. Сейчас нет идеального минификатора: чтобы и эффективным был, и делал все правильно. Ведь нужно учитывать не только особенности CSS, который постоянно меняется, но и уровень его поддержки браузерами, их баги, префиксы, хаки и т.д. Все это требует решения ряда непростых задач. Поговорим об этом, а также о принципах работы CSS-минификаторов, новых идеях и развитии CSSO.
Занимаясь разработкой интерфейсов, мы постоянно разбираемся как и что устроено. Вы задумывались, сколько времени у вас уходит на то, чтобы найти нужный фрагмент кода, который отвечает за компонент на странице? В своем докладе я покажу как это можно сделать за один клик, а так же раскрою технические детали.
Есть такая штука как инструментирование кода. Мало кто знает о ней, даже пользуясь результатами ее применения. Между тем, с инструментированием можно делать много всего интересного и, главное, полезного. Например, это может вам помочь лучше понять код или сделать процесс разработки более эффективным. Примеры инструментирования кода и принципы его работы.
Шаблонизаторы упрощают процесс формирования HTML и только. Но браузеру нужен совсем не HTML, а DOM. Необходимо преобразование. И вот тут начинается самое интересное: танцы с бубном и стрельба по ногам. В докладе пойдёт речь об общепринятом подходе получения DOM фрагмента, постпроцессинге и альтернативах. Сравним, измерим и узнаем как это делать быстрее всего.
Использование компонентного подхода это тяжеловесно, медленно, не гибко. Так ли это?
Доклад с фестиваля 404, Самара, 13 октября 2013
Видео: https://www.youtube.com/watch?v=QpZy0WW0Ig4
Basis.js - почему я не бросил разрабатывать свой фреймворк (extended)Roman Dvornov
Опенсорсный JavaScript-фреймворк с нестандартными подходами, ориентированный на разработку одностраничных приложений. Обновление шаблонов и стилей без перезагрузки страницы, развитые механизмы работы с данными, высокая производительность, инструменты разработчика и многое другое.
Доклад с конференции WSD, Санкт-Петербург, 8 июня 2013
Видео: http://www.youtube.com/watch?v=cVbbkwkhNQg
4. Производительность Frontend'а
• Не всегда проблема (и так быстро)
• Если работает медленно, не всегда это
связано с JavaScript (особенно в браузере)
• Доклад про те ситуации, когда проблема
действительно в JavaScript
4
6. Простого ответа нет
• Нужно разбирать каждый случай отдельно
• Пара символов или строк могут изменить
производительность в разы или даже в десятки раз
• На производительность могут влиять внешние факторы
• Тема производительности JavaScript все еще
не стабильна – все меняется
• Тема огромная, многие аспекты требуют предварительной
подготовки
6
7. В общем случае, нужно понимать как
работают JavaScript движки,
что фактически происходит под капотом,
принимать меры там, где это нужно
7
8. О чем поговорим
• Заблуждения
• Новое в JavaScript
• Внешнее влияние на производительность
• Что можно найти под капотом
8
14. switch vs. hasOwnProperty
14
function testSwitch(quality){
switch (quality) {
case "Hard Working":
case "Honest":
case "Intelligent":
case "Team player":
return true;
default:
return false;
}
}
var o = {
'Hard Working': true,
'Honest': true,
'Intelligent': true,
'Team player': true
};
function testHOP(quality) {
return o.hasOwnProperty(quality)
}
Нужно перебирать
все варианты – медленно
Быстрее и гибче
16. Значит switch быстрее hasOwnProperty?
• Не всегда, в данном случае – да
• В общем случае (в режиме интерпретатора)
обычно медленнее
• Время switch в примере обусловлено его
оптимизацией при компиляции
• В то же время, hasOwnProperty не оптимизируется
16
17. Намеренно деоптимизируем
17
try/catch не дает функции оптимизироваться (V8)
function testSwitch(quality){
try{}catch(e){}
switch (quality) {
case "Hard Working":
case "Honest":
case "Intelligent":
case "Team player":
return true;
default:
return false;
}
}
var o = {
'Hard Working': true,
'Honest': true,
'Intelligent': true,
'Team player': true
};
function testHOP(quality) {
try{}catch(e){}
return o.hasOwnProperty(quality)
}
19. Выводы
• switch работает быстро, если оптимизируется
• другой код может помешать оптимизации
• могут быть дополнительные ограничения:
например, ранее V8 не оптимизировал switch
если вариантов (case) более 128
19
21. for..in vs. Object.keys()
21
for (var key in object) {
// do something
}
for..in – плохо, потому что перебираются как
собственные ключи так и ключи в цепочке
прототипов
22. for..in vs. Object.keys()
22
for (var key in object) {
if (object.hasOwnProperty(key)) {
// do something
}
}
лучше проверять, что ключ является собственным,
но это дополнительная проверка
23. for..in vs. Object.keys()
23
var keys = Object.keys(object);
for (var i = 0; i < keys.length; i++){
// do something
}
Object.keys() возвращает только собственные
ключи – это лучше и быстрее
25. Разбираемся
25
for..in действительно перебирает как
собственные ключи так и ключи в цепочке
прототипов – это сложно оптимизировать и
стоит избегать
for (var key in object) {
// do something
}
26. Разбираемся
26
дополнительная проверка позволяет оптимизатору
распознать паттерн и сгенерировать код, который
не будет трогать цепочку прототипов
for (var key in object) {
if (object.hasOwnProperty(key)) {
// do something
}
}
27. Разбираемся
27
да, Object.keys() перебирает только собственные
ключи и это быстро, но в результате создается
временный массив, который нужно итерировать,
к тому же это создает нагрузку на GC
var keys = Object.keys(object);
for (var i = 0; i < keys.length; i++){
// do something
}
28. for..in vs. Object.key()
28
forIn: 170 ms
forInHOP: 56 ms
objectKeys: 188 ms
С оптимизацией
forIn: 202 ms
forInHOP: 232 ms
objectKeys: 244 ms
Без оптимизации
29. Выводы
• for..in в общем случае немного быстрее
• hasOwnProperty проверка может приводить
к лучшей оптимизации for..in
• Object.keys() может и отрабатывает быстрее,
но генерирует мусор и не оптимизируется
29
32. Оптимизация циклов
32
for (var i = 0, len = array.length; i < len; i++) {
// do something
}
нужно его ускорить, закешировав длину
массива, но и это не самый быстрый вариант
34. Тест автора статьи
34
var arr = [];
for (var i = 0; i <= 1000000; i++) {
arr.push(i);
}
console.time("slowLoop");
for (var k = 0, len = arr.length; k < len; k++) {
// do something
}
console.timeEnd("slowLoop");
console.time("fastLoop");
var j = arr.length;
while (j--) {
// do something
}
console.timeEnd("fastLoop");
36. На самом деле…
• В последних браузерах "slowLoop" обычно
быстрее "fastLoop"
• Временные интервалы малы, в таких случаях
велика погрешность
• Сам по себе тест неверный
36
37. Разбираемся
37
var arr = [];
for (var i = 0; i <= 1000000; i++) {
arr.push(i);
}
console.time("slowLoop");
for (var k = 0, len = arr.length; k < len; k++) {
// do something
}
console.timeEnd("slowLoop");
console.time("fastLoop");
var j = arr.length;
while (j--) {
// do something
}
console.timeEnd("fastLoop");
Изначально код не
оптимизуется – если код
выполняется лишь раз, нет
смысла оптимизировать
38. Разбираемся
38
var arr = [];
for (var i = 0; i <= 1000000; i++) {
arr.push(i);
}
console.time("slowLoop");
for (var k = 0, len = arr.length; k < len; k++) {
// do something
}
console.timeEnd("slowLoop");
console.time("fastLoop");
var j = arr.length;
while (j--) {
// do something
}
console.timeEnd("fastLoop");
Тело цикла выполняется
много раз и могло было бы
оптимизироваться, но
здесь оно пустое
39. Разбираемся
39
var arr = [];
for (var i = 0; i <= 1000000; i++) {
arr.push(i);
}
console.time("slowLoop");
for (var k = 0, len = arr.length; k < len; k++) {
// do something
}
console.timeEnd("slowLoop");
console.time("fastLoop");
var j = arr.length;
while (j--) {
// do something
}
console.timeEnd("fastLoop");
По сути сравнивается
время выполнения этих
инструкций
40. Выполним тест несколько раз
40
function test(){
console.time("slowLoop");
for (var k = 0, len = arr.length; k < len; k++) {
// do something
}
console.timeEnd("slowLoop");
console.time("fastLoop");
var j = arr.length;
while (j--) {
// do something;
}
console.timeEnd("fastLoop");
}
test();
test();
test();
42. Результаты
41
slowLoop: 3.00 ms
fastLoop: 2.07 ms
slowLoop: 0.85 ms
fastLoop: 1.38 ms
slowLoop: 1.14 ms
fastLoop: 1.57 ms
Первое исполнение без оптимизации
Последующие с оптимизацией
43. Промежуточные выводы
• Код оптимизируется по мере разогрева
• Простые функции оптимизируются на
втором-третьем вызове
• Оптимизированный код может поменять
картину
42
45. Поменяем подход к тестированию
44
function test(x){
loop {
x++;
}
return x;
}
console.time('test');
for (var i = 0, res = 0; i < 100; i++) {
res += test(i);
}
console.timeEnd('test');
• каждую функцию выполняем
несколько раз – даем
возможность оптимизациям
• добавляем одинаковую
полезную нагрузку –
увеличиваем время
выполнения уменьшаем
влияние погрешности
• избегаем dead code
elimination
47. Выводы
• while быстрее for – миф из прошлого
• для современных движков обычно нет
необходимости кешировать значения в циклах
• на скорость цикла больше влияет
оптимизация чем форма записи
46
49. Выводы
• Гипотезы нужно подтверждать тестами
• Часто код работает не так, как мы думаем
• Не стоит жить мифами, движки
эволюционируют – нужно освежать свои знания
• Микробенчмарки – зло, если создаются без
понимания работы движков
48
50. Советы
• Не стоит доверять всему, что пишут в интернетах
или говорят в докладах, перепроверяйте
• Наиболее точная информация в публикациях
разработчиков браузеров, движков и независимых
авторов, объясняющих почему именно так
• Смотрите на дату публикации, даже верные
утверждения могут устареть
49
54. Правда жизни
• Часто новые возможности реализуют по принципу
"чтобы работало" – без учета производительности
• Новые конструкции могут не оптимизироваться и
мешать оптимизации сопряженного кода
• Некоторые возможности из ES5/ES6/etc в
принципе не могут быть оптимизированы
и работать быстро
53
57. Однако, в V8 (Chrome/node.js)
let/const медленнее var в 2 раза,
в остальных движках время
одинаковое
56
jsperf.com/let-vs-var-performance/50
58. – Вячеслав Егоров
“... [const] это все-таки неизменяемая привязка
переменной к значению ...
С другой стороны виртуальная машина может и
должна бы использовать это самое свойство
неизменяемости ...
V8 не использует, к сожалению.”
57
habrahabr.ru/company/jugru/blog/301040/#comment_9622474
60. Два года назад, я решил узнать
насколько мой полифил для
Promise медленней нативной
реализации…
59
github.com/lahmatiy/es6-promise-polyfill
61. Тест №1
60
var a = []; // чтобы инстансы не разрушались/собирались GC
var t = performance.now();
for (var i = 0; i < 10000; i++)
a.push(new Promise(function(){}));
console.log(performance.now() - t);
62. Тест №2
61
var a = []; // чтобы инстансы не разрушались/собирались GC
var t = performance.now();
for (var i = 0; i < 10000; i++)
a.push(new Promise(function(r, rj){ a.push(r, rj) }));
console.log(performance.now() - t);
63. Promise – 2 года назад
62
gist.github.com/lahmatiy/d4d6316418fe349537dc
Test 1 Test 2
Native Polyfill Native Polyfill
Chrome 35 105 15 154 18
Firefox 30 90 17 113 25
IE11 – 5 – 6
время в миллисекундах
64. Promise – сегодня
63
Test 1 Test 2
Native Polyfill Native Polyfill
Chrome 54 12.5 5.8 13.7 8
Firefox 49 101 31 119.2 43.1
Edge 14 12.7 25.7 22.2 40.2
Safari 10 3.7 1.8 4.3 2.3
время в миллисекундах
65. Полифил Promise (не самый
быстрый) по прежнему быстрее
нативных реализаций
почти во всех движках/браузерах
64
66. Это афектит все Promise-based
API и новые фичи
вроде async/await
65
67. Я попытался еще ускорить
полифил Promise, например,
используя Function#bind вместо
замыканий…
66
70. Результаты – 2 года назад
69
gist.github.com/lahmatiy/3d97ee23f3d89941970f
Closure Function#bind
Chrome 35 14 28
Firefox 30 10.3 17.1
IE11 9.3 2.9
время в миллисекундах
71. Результаты – сегодня
70
Closure Function#bind
Chrome 54 2.5 0.8
Firefox 49 3.8 5.7
Edge 14 5.1 4.2
Safari 10 1.0 4.0
время в миллисекундах
78. Выводы
• Новое не всегда работает быстро
• Нужно время, чтобы в движки добавили
новые оптимизации и что-то заработало
быстро
77
79. Советы
• Все новое в JavaScript стоит проверять – работает
ли быстро, оптимизируется ли
• Стоит читать блоги/release notes разработчиков
движков и браузеров, в них пишут о добавлении
новых оптимизаций
• Критические к производительности места стоит
писать на ES3/ES5
78
84. Это не часть JavaScript, однако
API часто синхронное и время
его вызова прибавляется ко
времени выполнения JavaScript
83
85. Пример: DOM
84
function doSomething(el, viewport) {
el.style.width = viewport.offsetWidth + 'px';
el.style.height = viewport.offsetHeight + 'px';
}
С точки зрения JavaScript, здесь все просто
и нечего оптимизировать
86. Пример: DOM
85
function doSomething(el, viewport) {
el.style.width = viewport.offsetWidth + 'px';
el.style.height = viewport.offsetHeight + 'px';
}
Но для второго чтения потребуется сделать
пересчет layout'а (дорогая операция), так как
до этого был изменен DOM
87. Пример: DOM
86
function doSomething(el, viewport) {
var width = viewport.offsetWidth;
var height = viewport.offsetHeight;
el.style.width = width + 'px';
el.style.height = height + 'px';
}
В этом случае сначала делается чтение, потом
запись – код не тригирует пересчет layout'а
88. Стоит помнить
• Время выполнения внешних API добавляется
к JavaScript и останавливает его выполнение
• Не все, что доступно в JavaScript является
его частью
• Внешние API могут приводить к побочным
явлениям (side effect) затратным по времени
87
91. Выделение памяти
90
var array = [];
for (var i = 0; i < 1000; i++) {
array.push(i);
}
Плохо – может приводить к релокации
фрагментов памяти (массивы хранятся
одним фрагментом)
92. Выделение памяти
91
var array = new Array(1000);
for (var i = 0; i < 1000; i++) {
array[i] = i;
}
Лучше – может помочь избежать релокацию,
так как сразу выделится нужно кол-во памяти
93. Так же можно использовать структуры
данных, позволяющие избегать релокации,
например, TypedArray или списки
92
Подробнее в докладе:
Парсим CSS: performance tips & tricks
96. Влияние GC
95
> node --trace-gc test.js
...
[91494:0x102001000] 374 ms: Scavenge 35.3 (56.9) -> 35.0 (57.9) MB, 30.0 / 0.0 ms [allocation failure]
[91494:0x102001000] 443 ms: Scavenge 38.2 (59.9) -> 38.1 (74.9) MB, 46.2 / 0.0 ms [allocation failure]
===== run #1 152 ms
===== run #2 63 ms
===== run #3 44 ms
...
===== run #7 58
[91494:0x102001000] 896 ms: Scavenge 135.2 (159.9) -> 135.0 (160.9) MB, 31.5 / 0.0 ms [allocation fail
[91494:0x102001000] 965 ms: Scavenge 140.0 (163.9) -> 140.0 (178.9) MB, 59.2 / 0.0 ms [allocation fail
===== run #8 131 ms
===== run #9 43 ms
===== run #10 46 ms
97. Эволюция GC
• молодая и старая память
• инкрементальная сборка мусора
• параллельная сборка мусора
96
98. Простые советы
• Используем меньше памяти – быстрее
• Генерируем меньше мусора – быстрее
• Нужно понимать как происходит выделение
памяти и сборка мусора (GC)
97
100. Чтобы работать над ускорением
JavaScript, важно понимать как
устроены и работают JavaScript
движки
99
101. С чем стоит разобраться
• hidden class
• monomorphic, polymorphic, megamorphic
• inline cache
• function inlining
• dead code elimination
• tenuring
• ...
100
102. Хорошее начало – блог и
доклады Вячеслава Егорова
mrale.ph/blog/
101
104. Помимо этого
• Как работает железо (процессор, память –
регистры, адресация)
• Иметь преставление что такое машинный код
• Структуры данных (стек, etc)
• Как представляются структуры данных в
низкоуровневых языках (массивы, строки)
103
105. Самый верный способ узнать,
что на самом деле выполняет
движок – посмотреть внутреннее
представление
104
106. 105
node --trace-hydrogen
--trace-phase=Z
--trace-deopt
--code-comments
--hydrogen-track-positions
--redirect-code-traces
--redirect-code-traces-to=code.asm
--trace_hydrogen_file=code.cfg
--print-opt-code
your-script.js
Получаем данные о работе кода
110. Без понимания того, как
устроены JavaScript движки
крайне сложно писать
производительный код
109
111. Тема объемна – ее не постичь
за короткое время, потому
нужно понемногу в ней копаться
110
112. ВремясжатияCSS(600Kb)
500 ms
1 000 ms
1 500 ms
2 000 ms
2 500 ms
3 000 ms
3 500 ms
4 000 ms
4 500 ms
5 000 ms
5 500 ms
6 000 ms
Версия CSSO
1.4.0 1.5.0 1.6.0 1.7.0 1.8.0 2.0
1 050 ms
clean-css
Оно того стоит: изменение скорости CSSO
csso
500 ms
cssnano
23 250 ms
113. 112
CSSTree: 7 ms
Mensch: 31 ms
CSSOM: 36 ms
PostCSS: 38 ms
Rework: 81 ms
PostCSS Full: 100 ms
Gonzales: 175 ms
Stylecow: 176 ms
Gonzales PE: 214 ms
ParserLib: 414 ms
Оно того стоит: CSSTree
github.com/postcss/benchmark
Разбор bootstrap.css v3.3.7 (146Kb)
Парсер CSSTree появился в результате
многочисленного рефакторинга Gonzales
Подробнее в докладе:
Парсим CSS: performance tips & tricks
114. Ищите объяснения, почему что-то
работает быстро или медленно –
тогда вы сами сможете ответить
на вопрос как сделать ваш
JavaScript быстрее
113