Пару дней назад я писал про статью Эрика Кори об оптимизации регулярных выражений. Там есть ссылка, объясняющая почему JS обогнал C++ в бенчмарке regex-dna — "How did JavaScript beat C++ at the regex-dna benchmark?"
Regex-dna — это небольшая часть бенчмарка Sunspider, на который ориентируются разработчики JavaScript-движков на протяжении уже многих лет. В ходе соревнования друг с другом, реализации движков regex-выражений стали очень продвинуты. На данный момент Chrome и Firefox используют форк движка iiregexp. Его особенность состоит в том, что он компилирует регулярные выражения на лету в оптимизированный машинный код.
Хочу добавить, что сам по себе iiregexp написан на C++. В бенчмарке из вопроса сравнивали V8 и С++ код, использующий другой движок — re2. Интересно, какой бы был результат, если бы в C++ коде использовался iiregexp...
#regexp #performance #benchmark
https://www.quora.com/How-did-JavaScript-beat-C++-at-the-regex-dna-benchmark
Regex-dna — это небольшая часть бенчмарка Sunspider, на который ориентируются разработчики JavaScript-движков на протяжении уже многих лет. В ходе соревнования друг с другом, реализации движков regex-выражений стали очень продвинуты. На данный момент Chrome и Firefox используют форк движка iiregexp. Его особенность состоит в том, что он компилирует регулярные выражения на лету в оптимизированный машинный код.
Хочу добавить, что сам по себе iiregexp написан на C++. В бенчмарке из вопроса сравнивали V8 и С++ код, использующий другой движок — re2. Интересно, какой бы был результат, если бы в C++ коде использовался iiregexp...
#regexp #performance #benchmark
https://www.quora.com/How-did-JavaScript-beat-C++-at-the-regex-dna-benchmark
Quora
How did JavaScript beat C++ at the regex-dna benchmark?
Answer (1 of 4): JavaScript JIT-compiles the regexp to machine code.
The regexp-dna benchmark is part of the Sunspider benchmark suite for JavaScript implementations. The JavaScript engines competed on this benchmark for years, so anything that was part…
The regexp-dna benchmark is part of the Sunspider benchmark suite for JavaScript implementations. The JavaScript engines competed on this benchmark for years, so anything that was part…
Эверт Пот провёл эксперимент по измерению скорости HTTP/1.1 и HTTP/2 в разных условиях — "Performance testing HTTP/1.1 vs HTTP/2 vs HTTP/2 + Server Push for REST APIs".
Основные выводы из статьи. Если очень критична скорость, то нужно продолжать компоновать множество запросов в один. Если вас интересует более элегантный дизайн API, то получение каждой сущности по уникальному URL вполне хорошее решение в условиях HTTP/2. Кэширование ответов в Firefox незначительно влияет на общий результат, в Chrome эксперимент с использованием кэша показал прирост скорости в 2.3 раза. Есть проблемы с HTTP/2 Push в Firefox — автор статьи пишет, что push в его экспериментах работал через раз.
В общем, эта статья — ещё один повод задуматься о переходе с HTTP/1.1 на HTTP/2, если вы этого ещё не сделали.
#http #benchmark #performance
https://evertpot.com/h2-parallelism/
Основные выводы из статьи. Если очень критична скорость, то нужно продолжать компоновать множество запросов в один. Если вас интересует более элегантный дизайн API, то получение каждой сущности по уникальному URL вполне хорошее решение в условиях HTTP/2. Кэширование ответов в Firefox незначительно влияет на общий результат, в Chrome эксперимент с использованием кэша показал прирост скорости в 2.3 раза. Есть проблемы с HTTP/2 Push в Firefox — автор статьи пишет, что push в его экспериментах работал через раз.
В общем, эта статья — ещё один повод задуматься о переходе с HTTP/1.1 на HTTP/2, если вы этого ещё не сделали.
#http #benchmark #performance
https://evertpot.com/h2-parallelism/
Evertpot
Performance testing HTTP/1.1 vs HTTP/2 vs HTTP/2 + Server Push for REST APIs
Всегда ли WebP сжимает изображения лучше чем JPEG? Этим вопросом задался Йоханнес Сипола и написал статью "Is WebP really better than JPEG?"
Google в своих исследованиях про эффективность сжатия WebP говорил про уменьшение размеров изображений на 25-34% относительно JPEG. Йоханнес предполагает, что такая цифра получилась благодаря тому, что для создания JPEG-изображений использовался референсный кодировщик — cjpeg. В то время как существует более эффективный независимый кодировщик JPEG от Mozilla — MozJPEG. При сравнении разных наборов изображений из датасета от Kodak оказалось, что WebP уступает MozJPEG на больших изображениях. При этом во всех замерах с большим отрывом лидирует новый формат изображений — AVIF.
Выводы из статьи. Используйте WebP, когда сжимаются изображения меньше 500px, когда вы не можете использовать MozJPEG и когда вы можете использовать агрессивное сжатие с потерей качества.
#graphics #optimization #benchmark
https://siipo.la/blog/is-webp-really-better-than-jpeg
Google в своих исследованиях про эффективность сжатия WebP говорил про уменьшение размеров изображений на 25-34% относительно JPEG. Йоханнес предполагает, что такая цифра получилась благодаря тому, что для создания JPEG-изображений использовался референсный кодировщик — cjpeg. В то время как существует более эффективный независимый кодировщик JPEG от Mozilla — MozJPEG. При сравнении разных наборов изображений из датасета от Kodak оказалось, что WebP уступает MozJPEG на больших изображениях. При этом во всех замерах с большим отрывом лидирует новый формат изображений — AVIF.
Выводы из статьи. Используйте WebP, когда сжимаются изображения меньше 500px, когда вы не можете использовать MozJPEG и когда вы можете использовать агрессивное сжатие с потерей качества.
#graphics #optimization #benchmark
https://siipo.la/blog/is-webp-really-better-than-jpeg
siipo.la
Is WebP really better than JPEG?
If you have used tools like Google’s PageSpeed Insights, you probably have run into a suggestion to use “next-gen image formats”, namely Google’s WebP image format. Google claims that their WebP…
Дэниэл Александерсен поделился результатами сравнения WebP и AVIF в статье "Comparing AVIF vs WebP file sizes at the same DSSIM".
Дэниэл захотел улучшить качество изображений в своём блоге, сохранив их небольшой размер. Обычно все изображения кодировались с одними и тем же качеством. Такой подход иногда приводил к артефактам на одних изображениях и к избыточному размеру файлов на других, поэтому был выбран другой подход. Каждое изображение кодировалось несколько раз с индивидуальными настройками качества, затем бинарным поиском выбирались те изображения, которые были ближе всего к целевому показателю индекса DSSIM (аппроксимирует работу человеческого зрения и говорит о том, насколько изображения отличаются друг от друга).
При сравнении с оригинальными JPEG-изображениями медианное значение сокращения размера файлов при сжатии с помощью WebP составило 31.5%, у AVIF — 50.3%, на 85-ом перцинтиле 20% у WebP и 39.6% у AVIF. У WebP 2.7% изображений оказались больше оригинального изображения, у AVIF все изображения были меньше.
Рекомендую почитать статью всем, кто интересуется темой сжатия изображений.
#graphics #optimization #benchmark
https://www.ctrl.blog/entry/webp-avif-comparison.html
Дэниэл захотел улучшить качество изображений в своём блоге, сохранив их небольшой размер. Обычно все изображения кодировались с одними и тем же качеством. Такой подход иногда приводил к артефактам на одних изображениях и к избыточному размеру файлов на других, поэтому был выбран другой подход. Каждое изображение кодировалось несколько раз с индивидуальными настройками качества, затем бинарным поиском выбирались те изображения, которые были ближе всего к целевому показателю индекса DSSIM (аппроксимирует работу человеческого зрения и говорит о том, насколько изображения отличаются друг от друга).
При сравнении с оригинальными JPEG-изображениями медианное значение сокращения размера файлов при сжатии с помощью WebP составило 31.5%, у AVIF — 50.3%, на 85-ом перцинтиле 20% у WebP и 39.6% у AVIF. У WebP 2.7% изображений оказались больше оригинального изображения, у AVIF все изображения были меньше.
Рекомендую почитать статью всем, кто интересуется темой сжатия изображений.
#graphics #optimization #benchmark
https://www.ctrl.blog/entry/webp-avif-comparison.html
www.ctrl.blog
Comparing AVIF vs WebP file sizes at the same DSSIM
I got impressive results when comparing AVIF and WebP images at the same visual quality (using DSSIM.) AVIF’s 85th percentile was the same as WebP’s 15th!
Производительность стилизации в shadow DOM
Нолан Лоусон провёл небольшое исследование производительности стилизации в shadow DOM — "Does shadow DOM improve style performance?".
В пайплайне рендеринга браузера этап стилизации может занимать значительное время. В теории shadow DOM может его сократить, так как браузеру достаточно обработать инкапсулированные элементы. Проведённый бенчмарк подтвердил эту гипотезу, но только для сложных селекторов. Выигрыша относительно простых селекторов для
Выводы из статьи. Вариант оптимизации стилизации с помощью shadow DOM можно рассматривать при проектировании фреймворков. Shadow DOM не даёт прироста производительности относительно CSS Modules и других подобных решений для инкапсуляции стилей.
#css #performance #benchmark
https://nolanlawson.com/2021/08/15/does-shadow-dom-improve-style-performance/
Нолан Лоусон провёл небольшое исследование производительности стилизации в shadow DOM — "Does shadow DOM improve style performance?".
В пайплайне рендеринга браузера этап стилизации может занимать значительное время. В теории shadow DOM может его сократить, так как браузеру достаточно обработать инкапсулированные элементы. Проведённый бенчмарк подтвердил эту гипотезу, но только для сложных селекторов. Выигрыша относительно простых селекторов для
id и class нет.Выводы из статьи. Вариант оптимизации стилизации с помощью shadow DOM можно рассматривать при проектировании фреймворков. Shadow DOM не даёт прироста производительности относительно CSS Modules и других подобных решений для инкапсуляции стилей.
#css #performance #benchmark
https://nolanlawson.com/2021/08/15/does-shadow-dom-improve-style-performance/
Read the Tea Leaves
Does shadow DOM improve style performance?
Update: I wrote a follow-up post on this topic. Short answer: Kinda. It depends. And it might not be enough to make a big difference in the average web app. But it’s worth understanding why. …
Подходы использования SVG и их производительность
Тайлер Ситка сравнил производительность разных методов использования SVG на HTML-страницах — "Which SVG technique performs best for way too many icons?".
Самым производительным способом добавления SVG стал элемент <img> c data URI — 72 мс для 1000 иконок. Но при таком подходе невозможно стилизовать SVG с помощью внешних стилей. Наиболее сбалансированным способом для оптимизированных SVG оказался инлайнинг — 87 мс для 1000 иконок. Самым медленным способом стала CSS-маска — 150 мс.
Тайлер также пишет о том, что не нужно сильно задумываться о выборе подходящего метода, если на странице используется менее сотни SVG-изображений. Используйте тот подход, который нравится.
#benchmark #performance #svg
https://cloudfour.com/thinks/svg-icon-stress-test/
Тайлер Ситка сравнил производительность разных методов использования SVG на HTML-страницах — "Which SVG technique performs best for way too many icons?".
Самым производительным способом добавления SVG стал элемент <img> c data URI — 72 мс для 1000 иконок. Но при таком подходе невозможно стилизовать SVG с помощью внешних стилей. Наиболее сбалансированным способом для оптимизированных SVG оказался инлайнинг — 87 мс для 1000 иконок. Самым медленным способом стала CSS-маска — 150 мс.
Тайлер также пишет о том, что не нужно сильно задумываться о выборе подходящего метода, если на странице используется менее сотни SVG-изображений. Используйте тот подход, который нравится.
#benchmark #performance #svg
https://cloudfour.com/thinks/svg-icon-stress-test/
Cloud Four
Which SVG technique performs best for way too many icons?
When I started giving talks about SVG back in 2016, I'd occasionally hear a question I never had a great answer for: What if you have a lot of icons on a page?
Анализ производительности HTTP/3
В блоге requestmetrics была опубликована статья, посвящённая анализу производительности HTTP/3 — "HTTP/3 is Fast".
HTTP/3 — это новая версия протокола HTTP, работающая поверх транспортного протокола QUIC. Более подробно про HTTP/3 можно почитать в публикации HTTP/3: the past, the present, and the future.
В этой же статье проверялась скорость загрузки трёх видов сайтов: простой сайт, тяжёлый сайт, SPA. Ресурсы загружались с трёх разных серверов в Нью-Йорке, Лондоне и Бангалоре. Чем больше было расстояние, тем лучше всего показывал себя HTTP/3. Если для передачи данных между Миннесотой и Нью-Йорком выигрыш скорости составил более 200 мс, то для соединения между Миннесотой и Бангалором выигрыш был уже 3-4 секунды. Такой значительный разрыв в скорости загрузки объясняется тем, что в HTTP/3 решена проблема с “head-of-line blocking” — блокировкой передачи данных во время потери пакетов.
#http #performance #benchmark
https://requestmetrics.com/web-performance/http3-is-fast
В блоге requestmetrics была опубликована статья, посвящённая анализу производительности HTTP/3 — "HTTP/3 is Fast".
HTTP/3 — это новая версия протокола HTTP, работающая поверх транспортного протокола QUIC. Более подробно про HTTP/3 можно почитать в публикации HTTP/3: the past, the present, and the future.
В этой же статье проверялась скорость загрузки трёх видов сайтов: простой сайт, тяжёлый сайт, SPA. Ресурсы загружались с трёх разных серверов в Нью-Йорке, Лондоне и Бангалоре. Чем больше было расстояние, тем лучше всего показывал себя HTTP/3. Если для передачи данных между Миннесотой и Нью-Йорком выигрыш скорости составил более 200 мс, то для соединения между Миннесотой и Бангалором выигрыш был уже 3-4 секунды. Такой значительный разрыв в скорости загрузки объясняется тем, что в HTTP/3 решена проблема с “head-of-line blocking” — блокировкой передачи данных во время потери пакетов.
#http #performance #benchmark
https://requestmetrics.com/web-performance/http3-is-fast