Рубрика «производительность»

image

Мы, разработчики, всегда стремимся искать возможности повышения производительности приложений. Когда речь идёт о веб-приложениях, то улучшения обычно вносятся только в код.

Но думали ли вы об использовании мощи GPU для повышения производительности веб-приложений?

В этой статье я расскажу о библиотеке ускорения JavaScript под названием GPU.js, а также покажу вам, как повысить скорость сложных вычислений.

Что такое GPU.js и почему его стоит использовать?

Если вкратце, GPU.js — это библиотека ускорения JavaScript, которую можно использовать для любых стандартных вычислений на GPU при работе с JavaScript. Она поддерживает браузеры, Node.js и TypeScript.

Кроме повышения производительности если и множество других причин, по которым я рекомендую использовать GPU.js:

  • В основе GPU.js лежит JavaScript, что позволяет использовать синтаксис JavaScript.
  • Библиотека берёт на себя задачу автоматической транспиляции JavaScript на язык шейдеров и их компиляции.
  • Если в устройстве отсутствует GPU, она может «откатиться» к обычному движку JavaScript. То есть вы ничего не потеряете, работая с GPU.js.
  • GPU.js можно использовать и для параллельных вычислений. Кроме того, можно асинхронно выполнять множественные вычисления одновременно и на CPU, и на GPU.

Учитывая всё вышесказанное, я не вижу никаких причин не пользоваться GPU.js. Давайте узнаем, как его освоить.
Читать полностью »

Как мы устраняли ошибку Chrome, скрывавшуюся в коде со времён совместимости с Windows XP - 1

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

1%

Наши метрики показывают, что Chrome в среднем быстр, но временами может заметно притормаживать. Подобные страдания пользователей видны в 99-м перцентиле многих метрик, но невоспроизводимы, а поэтому с ними довольно сложно работать. Более глубокий анализ данных показывает, что «длинный хвост» производительности свойственен не 1% пользователей на медленных машинах, а множеству пользователей в 1% от общего времени.

Давайте поговорим об этом 1%. Читать полностью »

image

Джей Ситтер в своей статье "Люди подозревают, что технологии — отстой" пишет о людях, которые продолжают использовать технологии, несмотря на серьезные неприятности, такие как очень тусклый экран или постоянные всплывающие окна, и ничего не делают с этим. Он делает вывод:

Если бы мой экран был на 5% яркости или если бы я не мог использовать свой телефон, не нажимая «Отмена» каждые пять секунд, я бы тратил часы или дни на Google, пытаясь найти решение, если бы это было то, что мне нужно. То, что эти люди в основном просто мирились с проблемами, означает, что для них эти проблемы не могли быть заметно хуже, чем сама технология в своей основе.

Эти примеры немного экстремальны, но важно помнить, что они реальны. Это не преувеличение. Это происходило.

В обсуждениях в Твиттере люди продолжают отвечать, что этим пользователям следует:

  • сделать что-нибудь с этим,
  • искать замену,
  • или просто не делать ничего.

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

Чтобы доказать свою точку зрения, я решил записывать каждое прерванное действие в течение одного дня. Вот полный список, который я написал вчера, 24 сентября 2020 года:
Читать полностью »

Прим. перев.: в конце января Percona опубликовала результаты своего небольшого сравнения производительности для СУБД PostgreSQL, запущенной на x86- и ARM-инстансах AWS. Результаты получились интересными даже с учетом всех допущений, сделанных самими авторами и отмеченных комментаторами оригинальной статьи. А чтобы вы могли сделать собственные выводы, предлагаем вниманию перевод этого материала.

Читать полностью »

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

Мы отрендерили миллион страниц, чтобы понять, из-за чего тормозит веб - 1

  • Посещён 1 миллион страниц
  • Записано по 65 метрик каждой страницы
  • Запрошен 21 миллион URL
  • Зафиксировано 383 тысячи ошибок
  • Сохранено 88 миллионов глобальных переменных

Можно ли превзойти наш анализ? Мы опубликовали наш набор данных на Kaggle, поэтому вы можете обработать данные самостоятельно.

Зачем рендерить миллион веб-страниц?

Сегодня распространено мнение о том, что веб почему-то стал более медленным и забагованным, чем 15 лет назад. Из-за постоянно растущей кучи JavaScript, фреймворков, веб-шрифтов и полифилов, мы съели все преимущества, которые даёт нам увеличение возможностей компьютеров, сетей и протоколов. По крайней мере, так утверждает молва. Мы хотели проверить, правда ли это на самом деле, а также найти общие факторы, которые становятся причиной торможения и поломок сайтов в 2020 году.

Общий план был простым: написать скрипт для веб-браузера, заставить его рендерить корневую страницу миллиона самых популярных доменов и зафиксировать все мыслимые метрики: время рендеринга, количество запросов, перерисовку, ошибки JavaScript, используемые библиотеки и т.п. Имея на руках все эти данные, мы могли бы начать задаваться вопросами о том, как один фактор корреллирует с другим. Какие факторы сильнее всего влияют на замедление рендеринга? Какие библиотеки увеличивают время до момента возможности взаимодействия со страницей (time-to-interactive)? Какие ошибки встречаются наиболее часто, и что их вызывает?
Читать полностью »

Да ты гонишь! Почему на одних конфигурациях оперативка разгоняется выше, чем на других - 1

Разгон памяти, дело добровольное. Как понять, от чего зависит разгон памяти, какие есть тонкости в подборе комплектующих и как «прогнать» память, чтобы было за нее не стыдно!
Изучение, анализ и подбор – три составляющих успеха в разгоне памяти. Чтобы начать разгонять память без погружения в пучины технических знаний, необязательно быть специалистом. Половина успеха зависит от платформы, вторая часть – это правильный выбор ранговости, количество модулей и частот памяти Kingston и HyperX.
Читать полностью »

Кто такой «1х-инженер»?

Возможно, вы слышали о «десятикратных» инженерах. Они очень производительны, эффективны, работают буквально за десятерых. Если такие существуют, то наверняка должны быть и одинарные инженеры?

Конечно, такие есть. Давайте попробуем составить список качеств, присущих простому одинарному инженеру. Неполный список.
Читать полностью »

3 сентября мы провели 18-й Angular Meetup. В этот раз все доклады были объединены общей темой: говорили о разных аспектах производительности Angular-приложений.

Из-за пандемии сами знаете чего наша жизнь сильно изменилась и по большей части не к лучшему. Но есть и хорошие новости: никогда раньше международные мероприятия и мировые эксперты не были так доступны и близки. Мы тоже решили извлечь максимум из жизни онлайн и на 18-й Angular Moscow пригласили двух зарубежных экспертов со статусом GDE.

В посте вы найдете тезисы и видео докладов, а также ссылку на страницу с презентациями.

Читать полностью »

С таким понятием, как измерение производительности рано или поздно сталкивается, наверное, абсолютно каждый программист.

В любой конторе, в любом коллективе, да даже, когда вы наедине со своим Тайлером Дерденом (но только, если ваш Тайлер — программист), обязательно, хотя бы раз, зайдет спор о том, как реализовать ту или иную функцию, чтобы она работала быстро. Но быстро, как характеристика обычно не котируется, поэтому предлагаю поговорить о том, как абстрактное быстро превращать в неабстрактное число.

Читать полностью »

Прим. перев.: эту статью написал старший DevOps-инженер американской компании Olark, главный продукт которой — live chat — используют тысячи организаций. Автор делится размышлениями о проблеме потребляемых ресуров при сборе логов и результатами своего эксперимента с fluentd, что позволил ему добиться лучшей производительности для некоторых сценариев.

Цена tailing'а логов в Kubernetes - 1

Журналирование – одна из тех вещей, о которых вспоминают только тогда, когда они ломаются. И это вовсе не критика. Дело в том, что логи как таковые не приносят денег. Они позволяют получать представление о том, что делают (или делали) программы, помогая поддерживать работу того, что приносит нам деньги. На малых масштабах (или при разработке) необходимую информацию можно получить, просто выводя сообщения в stdout. Но стоит перейти к распределенной системе, и сразу возникает потребность агрегировать эти сообщения и направлять в некое центральное хранилище, где они принесут наибольшую пользу. Это потребность еще более актуальна, если вы имеете дело с контейнерами на платформе вроде Kubernetes, где процессы и локальное хранилище эфемерны.Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js