Для Ruby и Ruby on Rails разработчиков уровня Junior+, Middle
Рубрика «оптимизация кода» - 2
Оптимизируем память Rails сервиса (реальный кейс)
2020-03-30 в 16:37, admin, рубрики: garbage collector, ruby, ruby on rails, оптимизация, оптимизация кода, оптимизация программ, память процессаВалидация ассетов в Unity3D
2020-03-06 в 8:46, admin, рубрики: C#, game development, Gamedev, unity, unity3d, ассеты, Блог компании Pixonic, валидация, геймдев, оптимизация кода, оптимизация рабочего времени, разработка игр, сериализация
Начнём с того, что я обожаю сериализацию в Unity. Она надёжна и очень проста в использовании. Я просто расширяю MonoBehaviour, ScriptableObject и подобные классы и настраиваю сериализуемые поля экземпляров в инспекторе.
Но у неё есть и слабости. Одна из них ― человеческий фактор. Представьте себе огромный проект, который живёт несколько лет и над которым работает около сотни человек. И любой из них может совершить ошибку: оставить пустую ссылку на объект, указать число вне диапазона, ввести строку в неверном формате, заполнить массив слишком маленьким или, наоборот, слишком большим количеством объектов. Уверен, у каждого из вас найдутся такие примеры из своего опыта. Причин и оправданий тоже множество: невнимательность, неожиданные последствия слияния веток, сбои редактора… И никто от этого не застрахован.
Такие ошибки до поры до времени остаются незаметными: компилятору до них нет дела, в отличие от опечаток в коде. Особенно неприятны они тем, что проявляются часто уже во время выполнения кода. Только тогда вы начинаете читать журнал сообщений и идёте проверять данные: тыкать их в редакторе или листать YAML. Но объектов может быть достаточно много, есть риск что-то пропустить или попросту залениться.
Конечно, можно добавить проверок в коде, но от этого он загрязнится. Иногда эти проверки негативно влияют на производительность. А ещё не всегда однозначно понятно, как именно обработать каждую конкретную ошибку.
Универсального или даже штатного метода бороться с подобным в Unity нет. Поэтому мы в Pixonic реализовали свою систему валидации ассетов. И это очень помогает нам жить.
Сейчас я опишу, как там всё устроено.
Читать полностью »
Сканирующее окно по массивам NumPy
2020-02-24 в 15:19, admin, рубрики: moving window, numpy, python, rolling window, sliding window, Алгоритмы, массивы, метод скользящего окна, оптимизация кода, Программирование, Совершенный кодCoLab блокнот с примерами
Возможно сделать скользящее окно (rolling window, sliding window, moving window) по массивам NumPy на языке программирования Python без явных циклов. В данной статье рассматривается создание одно-, двух-, трех- и N-мерных скользящих окон по массивам NumPy. В результате скорость обработки данных увеличивается в несколько тысяч раз и сравнима по скорости с языком программирования С.
Cкользящее окно применяется в: обработке изображений, искусственных нейронных сетях, интернет протоколе TCP, обработке геномных данных, прогнозировании временных рядов и т.д.
Отказ от ответственности: в исходном коде могут быть ошибки! Если вы видите ошибку, пожалуйста, напишите мне.
Железо или оптимизация? Badoo, Авито и Мамба — о производительности PHP
2020-02-06 в 12:01, admin, рубрики: php, Блог компании Badoo, бэкенд, высокая производительность, конференции, оптимизация, оптимизация кода, производительностьВопрос производительности PHP-кода для Badoo один из самых важных. От качества PHP-бэкенда напрямую зависят количество ресурсов, которые мы тратим на разработку и эксплуатацию, скорость работы сервиса и впечатление, которое он производит на пользователей.
Поэтому темой третьей встречи сообщества PHP-разработчиков в нашем офисе мы сделали производительность бэкенда и пригласили к обсуждению коллег из Авито и «Мамбы».
Читайте под катом расшифровку дискуссии, в которой мне повезло быть модератором: как устроена инфраструктура трёх компаний, как мы измеряем производительность и на какие метрики ориентируемся, какие инструменты используем, как делаем выбор между железом и оптимизацией.
А 15 февраля приходите на следующий Badoo PHP Meetup: обсудим легаси.
Читать полностью »
Ох уж этот медленный C-C++
2020-01-14 в 19:14, admin, рубрики: C, c++, Алгоритмы, высокая производительность, оптимизация кода, ПрограммированиеЭто небольшое подведение итогов на пост “Быстрее, чем C++; медленнее, чем PHP”
Неблагодарное дело — «спорить» в комментариях, поэтому формулирую несколько мыслей в отдельный пост. Автор утверждал тут, тут, и еще много где, что у него большой стаж и богатый опыт в программировании на С++.
Читать полностью »
Оптимизация Unity: как вас обкрадывает иерархия сцен
2019-12-23 в 12:52, admin, рубрики: unity, игровые движки, Клиентская оптимизация, оптимизация кода, профилирование производительности, разработка игрИтак, вы оптимизировали самые очевидные части своей игры. Однако на самом деле это не так. Вы упустили хитрый, не совсем заметный момент: оптимизацию иерархии сцены Unity.
А что не так с иерархией? Позвольте вам кое-что показать.
Запустите Unity и откройте проект своей игры. Затем запустите игру на целевом устройстве
и подключите к ней Unity Profiler. Запишите несколько кадров во время игрового процесса.
В Unity Profiler поищите следующие неприятные маркеры профайлера:
Не нашли? Продолжайте искать, уверен, найдётся хотя бы один.
Это могут быть UpdateRendererBoundingVolumes, Physics.SyncColliderTransform или TransformChangedDispatch.
Они появятся, когда вы уже будете готовы сдаться. Они возникнут, когда вы уже наведёте курсор мыши на кнопку закрытия Profiler.
Нашли? Если да, то вам повезло. Я тоже нашёл их в одном из своих предыдущих проектов и узнал, как полностью избавиться от них. Я понял, какое зло в них скрыто…
Хотите узнать секреты производительности иерархий сцен Unity?
Читать полностью »
Clang-format тормозит работу программы
2019-12-12 в 17:34, admin, рубрики: c++, clang, Блог компании PVS-Studio, детектив, Компиляторы, оптимизация, оптимизация кодаСегодня мы будем измерять производительность разных реализаций функции toupper, ведь именно этим и занимаются по вторникам.
Вообще-то мне нет никакого дела до функции toupper, просто я недавно писал другой пост и мне нужен был какой-то общий сюжетный стержень, а toupper кажется вполне интересным и безобидным кандидатом в бенчмарки. Я старался выбрать что-то максимально простое, что не увело бы меня в сторону, но так уж получилось, что в этом тесте я столкнулся со странной проблемой.
Читать полностью »
Как линейное время превращается в Windows в O(n²)
2019-12-10 в 13:41, admin, рубрики: windows management instrumentation, WMI, вычислительная сложность, Клиентская оптимизация, о большое, оптимизация кода, разработка под windows, реверс-инжиниринг, тормоза
Недавно я столкнулся с многоминутными задержками на моей рабочей станции. После расследования выяснилось, что причина проблемы заключалась в блокировке, которая могла длиться по пять минут, во время которых источник блокировки в основном крутился в цикле из девяти инструкций.
Для меня очень важно подбирать хорошие заголовки для своих постов, но я сразу же вспомнил, что подходящее название «48 процессора заблокированы девятью инструкциями» уже занято [перевод на Хабре] постом, написанным меньше месяца назад. Количество заблокированных процессоров отличается, а цикл немного длиннее, но на самом деле всё это заставляет испытывать дежавю. Поэтому пока я объясняю новую найденную проблему, мне был хотелось поразмыслить над тем, почему это случается постоянно.
Почему это происходит?
Грубо говоря, такие проблемы возникают вследствие наблюдения, которое я назову Первым законом Доусона о вычислениях: O(n2) — это магнит для алгоритмов, которые плохо масштабируются: они достаточно быстры, чтобы попасть в продакшен, но достаточно медленны, чтобы всё портить, когда туда попадут.
O(n2) в действии — данные взяты из моего случая
Читать полностью »
Краеугольные камни уничтожения медленного кода в Wolfram Language: ускоряем код в десятки, сотни и тысячи раз
2019-11-08 в 15:01, admin, рубрики: CUDA, opencl, Wolfram, wolfram language, wolfram mathematica, абсолютная точность, Алгоритмы, ассоциативные массивы, Блог компании Wolfram Research, векторизация, вычисления, дебаг, компиляция, компиляция в c, машинная точность, мемоизация, оптимизация кода, отладка, плавающая запятая, правила замены, Программирование, распараллеливание, символьные вычисления, списки, точность, ускорение кода, функциональное программирование, хеш-таблицы, хэширование, шаблоныСкачать файл с кодом и данные можно в оригинале поста в моем блоге
Картинка к вебинару и посту взята не просто так: в определенном смысле символьное ядро Wolfram Language можно сравнить с Таносом — если бы его мощь была бы направлена в правильное русло, он мог бы стать самым мощным и полезным «добряком». Так же и с символьным ядром Wolfram — его чудовищную мощь нужно правильно использовать, а если это делать не так, оно может стать настоящим «злом», замедляющим все очень сильно. Начинающие разработчики не знают многих важнейших парадигм, идей и принципов языка Wolfram Language, пишут код, который на самом деле дико неэффективен и после этого разочаровываются, хотя тут нет вины Wolfram Language. Эту ситуацию призвана исправить эта статья.
Мне довелось работать с Wolfram Language начиная с (уже довольно далекого) 2005 года (тогда еще была версия Mathematica 5.2, сейчас уже 12-я). За эти почти 15 лет произошло очень много: добавились тысячи новых встроенных функций и областей, в которых они работают (машинное обучение, точная геометрия, работа с аудио, работа в вебе, облачные возможности, глубокая поддержка единиц измерения, интеграция с базами данных Wolfram|Alpha, географические вычисления, поддержка работы с CUDA, Python, распараллеливание операций и многое многое другое), появились новые сервисы — облако Wolfram Cloud, широко известная система вычислительных значeний Wolfram|Alpha, репозиторий функций, репозиторий нейросетей и пр.
Читать полностью »
Делись, рыбка, быстро и нацело
2019-09-23 в 19:36, admin, рубрики: asm, c++, Алгоритмы, ассемблер, деление нацело, математика, оптимизация кода
Деление — одна из самых дорогих операций в современных процессорах. За доказательством далеко ходить не нужно: Agner Fog[1] вещает, что на процессорах Intel / AMD мы легко можем получить Latency в 25-119 clock cycles, а reciprocal throughput — 25-120. В переводе на Русский — МЕДЛЕННО! Тем не менее, возможность избежать инструкции деления в вашем коде — есть. И в этой статье, я расскажу как это работает, в частности в современных компиляторах(они то, умеют так уже лет 20 как), а также, расскажу как полученное знание можно использовать для того чтобы сделать код лучше, быстрее, мощнее.
Читать полностью »