Клиентская оптимизация *

Часть I: Основы

«В теории теория и практика одинаковы. На практике это не так». — авторство приписывается разными специалистам по computer science

Загадка

Два часа утра. Я смотрю на совершенно нелогичные данные профилирования.

В процессе работы над загрузчиком для SoC RISC-V у нас возникла проблема с производительностью. Загрузчик должен был искать конфигурации устройств в таблице: примерно пятьсот элементов, каждый с 32-битным ID устройства и указателем на данные конфигурации. Всё просто.

Мой коллега реализовал эту систему с помощью хэш-таблицы. «Поиск за O(1), — сказал он уверенно, — лучше уже некуда».

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

Я попробовал использовать очевидную оптимизацию: заменить хэш-таблицу двоичным поиском по отсортированному массиву. Двоичный поиск занимает O(log n), что теоретически хуже, чем O(1). Так написано в учебниках. Мой преподаватель алгоритмов был бы разочарован.

Но в результате загрузчик оказался на 40% быстрее.

Как O(log n) смогло победить O(1)? Что происходит?

Base64 — это схема кодирования двоичных значений в текст, преобразующая произвольные двоичные данные (например, изображения, файлы или любые байтовые последовательности) в безопасную печатную ASCII-строку, состоящую из 64-символьного алфавита (A–Z, a–z, 0–9, +, /). Браузеры применяют эту схему в JavaScript для встраивания двоичных данных непосредственно в код/HTML или для передачи двоичных данных в виде текста.

Недавно в браузерах появились удобные и безопасные функции для обработки Base64: Uint8Array.toBase64() и Uint8Array.fromBase64(). Хоть у них и есть множество параметров, смысл их сводится к кодированию и декодированию.

При кодировании они берут 24 бита из входных данных и разделяют их на четыре сегмента по 6 бит, и каждое 6-битное значение (в интервале от 0 до 63) соотносится с конкретным символом из алфавита Base64: первые 26 символов — это буквы A-Z в верхнем регистре, следующие 26 — a-z в нижнем, затем идут цифры 0-9 и, наконец, символы «+» и «/» в качестве 62-го и 63-го символов. Если длина входных данных не кратна трём байтам, то в качестве заполнителя используется знак «=».

Насколько же быстро могут работать эти функции?

Система ЕРИП (Автоматизированная информационная система «Расчет») функционирует в Беларуси с 2008 года. До недавнего времени для предпринимателей и бизнесменов, принимающих через нее платежи, возврат средств был болезненной темой. Уведомление о платеже поступало мгновенно — а вот вернуть деньги клиенту можно было только через многоэтапную, ручную процедуру, требующую сбора реквизитов, согласований и ожидания. 

Недавно возвраты в ЕРИП перешли в полноценный онлайн-режим — и это не не просто хорошая новость, а реальный рабочий инструмент для бизнеса, в том числе ресторанного, туристического, гостиничного, по аренде недвижимости и др.

Разбираемся, что изменилось и как агрегаторы превращают возвраты в полуавтоматическую операцию за пару минут.

Очень краткий рассказ про семь проектов, построенных одним инженером на унаследованной платформе.

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

Хотелось не просто ускорить метрики, а выстроить полноценную систему, которая бы работала для пользователя как обычное SPA-приложение: быстро, плавно, визуально современно, а главное с уважением к пользователям.

Минимализм в UI часто воспринимается как эстетический выбор. Но на самом деле за ним стоят измеримые нейробиологические механизмы: ограничения рабочей памяти, дофаминовое подкрепление, гештальт-принципы восприятия и влияние цвета на уровень стресса.

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

ЗРИ В КОРЕНЬ:            
Про вызовы текущего момента в очень простой двоичной логике (специально для ХАБРа).

В качестве введения

 Те, кто системнее понимает прикладную задачу (структуру, условия, взаимосвязи), тот сделает лучшую постановку задачи и достигнет больших результатов от ее решения. Поэтому предлагаю читателям ХАБРа познакомиться с системным подходом для анализа Прикладного промышленного мира и постановкой задачи по радикальному повышению экономической эффективности деятельности промышленных предприятий/цепей поставок от эксперта консалтинговой группы компаний «Приоритет».

Я поделюсь знаниями из нашей «внутренней кухни», чтобы содействовать сближению видения представителей Прикладного промышленного и IT миров на постановку задачи: «Что делать, чтобы стать лучше? Намного лучше!».

 Глава 1. «Бытие определяет сознание, или что происходит и к чему это обязывает?»

 Пара вопросов в качестве разогрева и гимнастики для ума:

В этой статье я представлю мой завершённый очень быстрый алгоритм преобразования дат.. Он обеспечивает существенный прирост скорости, по величине сравнимый с приростом, достигнутым предыдущим самым быстрым алгоритмом (Neri-Schneider 2021) относительно его предшественника (C++ Boost). Полная реализация алгоритма на C++ выпущена как свободное и бесплатное ПО (лицензия BSL-1.0).

Алгоритм генерирует точные результаты за период ±1,89 триллиона лет, поэтому подходит для обработки полного 64-битного времени UNIX (в секундах).

В этом посте будут объяснены две стратегии оптимизации WebAssembly, которые не так давно были реализованы в движке V8 и вошли в версию браузера Google Chrome M137. Речь пойдёт о спекулятивном встраивании call_indirect inlining и о поддержке деоптимизации в WebAssembly. В сочетании два этих приёма помогают генерировать более качественный машинный код, так как основаны на допущениях, которые строятся, исходя из обратной связи, поступающей от среды исполнения. Благодаря этому, WebAssembly выполняется быстрее, особенно это касается программ WasmGC. Например, проверив эти приёмы на наборе микробенчмарков, написанных на Dart, видим, что комбинация двух оптимизаций даёт ускорение в среднем более чем на 50%. В более крупных и реалистичных приложениях и на тех бенчмарках, которые рассмотрены ниже, достигается ускорение между 1% и 8%. Деоптимизации — также очень важная составляющая для дальнейшей оптимизации в будущем.

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

Раньше для этого можно было использовать только строку User‑Agent, которую браузер отправляет автоматически, но её избыточность и сложность парсинга стали сдерживать развитие веба. Client Hints предлагает другой подход: вместо того чтобы сразу раскрывать всю информацию, браузер передаёт только те данные, которые действительно нужны сайту.

На связи Степан из команды Яндекс Браузера. Сегодня поговорим о том, как мы переходим от устаревшего User‑Agent к современной технологии Client Hints. В статье разберём, почему User‑Agent стал проблемой, как работают хинты под капотом и какие перспективы у перехода на новую технологию.

Прошло почти 5 лет с момента вскрытия уязвимости кнопки «Безопасность» в сервисе Яндекс.Такси, который ныне зовётся YandexGo. Но я снова решил сожрать тот же кактус.

И отправил двух дорогих мне людей на этом сервисе...

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

Язык программирования C#, несмотря на то, что обеспечивает автоматическое управление памятью с помощью механизма сборки мусора (GC), требует от разработчиков специальных знаний и навыков для оптимизации работы с памятью.

Всем привет! Сегодня хотелось бы затронуть такую тему, как оптимизация CPU для ваших приложений на C#.  В целом, эффективное использование вычислительных ресурсов, включая процессор, является одним из главных аспектов разработки программного обеспечения. В этой статье мы рассмотрим несколько ключевых подходов и стратегий оптимизации нагрузки на CPU в языке программирования C#.

В одном из моих докладов по ассемблеру я показал список из 20 самых часто исполняемых команд на среднем десктопе x86 с Linux. Разумеется, в этом списке были привычные  mov, add, lea, sub, jmp, call и так далее; неожиданным стало включение в него xor — «eXclusive OR». В эпоху, когда я занимался хакингом на 6502, наличие XOR было почти абсолютно точным указанием на то, что найдена часть кода, связанная с шифрованием, или какая-то подпрограмма обработки спрайтов. Поэтому удивительно, что машина с Linux, просто занимающаяся своими делами, выполняет такое количество этих команд.

Но потом мы вспоминаем о том, что компиляторы любят генерировать xor при присвоении регистру нулевого значения.

С нуля собрали кредитное PWA-приложение за 6 месяцев. Рассказываем, какие решения помогли быстро выйти на рынок и выдержать рост.

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

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

Всем привет! Меня зовут Сергей Бунатян, я руководитель службы в Техплатформе Городских сервисов Яндекса. 

На сегодняшний день существует довольно много брокеров сообщений. Наиболее часто используемыми в индустрии, пожалуй, будут те, которые, реализуют парадигму очереди сообщений. Самых известных представителей вы наверняка знаете, — Apache Kafka и RabbitMQ, а внутри Яндекса широко используется Logbroker. И, тем не менее, как нетрудно догадаться из этого вступления, мы зачем‑то решили написать свой брокер сообщений.

Сегодня я расскажу про нашу систему, которая называется STQ — Sharded Tasks Queue. По названию системы можно было бы подумать, что это ещё один сервер очередей, однако это будет не совсем верно. STQ — это скорее message broker. 

В этой статье я постараюсь рассказать о том, какие задачи перед нами стояли и как это нас привело к решению написать что‑то своё. А заодно поделюсь опытом эксплуатации нашей системы и расскажу про влияние STQ на опыт разработчиков.

Вы работаете над устоявшимся продуктом, в котором уже достигли PMF. Ваша команда выкатывает новую фичу за фичой. A/B‑тесты показывают +3% к конверсии. Продакт ставит задачам статус «Done», команда получает поздравления от СРО. А через два месяца выясняется: 40% пользователей по‑прежнему отваливаются на том же критичном шаге. Проблема не решена. Но в бэклоге она больше не приоритетна — там уже 47 других «важных» задач. СРО требует результат. Кажется что‑то не так.

Привет, Хабр! Меня зовут Алексей, я занимаюсь беспроводными технологиями и сегодня хочу рассказать об опыте проведения большого исследования - опроса абонентов провайдеров, который охватил почти сто тысяч абонентов и длился больше трёх лет. История, которая началась как товарищеский спор, но которая быстро смогла нас всех увлечь и поразить полученными результатами. Это был действительно увлекательный опыт. Первые опросы мы проводили в домовых чатах, до которых могли достучаться, и нужно сказать, что это, наверное, самый действенный механизм взаимодействия с целевой аудиторией. Затем мы создавали опросы в Google и Яндекс.Формах, пробовали даже поднять свою опросную платформу на базе Limesurvey, привлекали в качестве помощников в опросе студентов (спасибо коллегам из вузов и студенческих профсоюзов). Некоторые ответы ставили нас в тупик, а некоторые порождали ещё больше вопросов. Тогда мы отступали на шаг, проводили проблемные интервью с некоторыми из опрашиваемых и вновь повторяли опросы.

Это история о том, как написать компилятор Python, генерирующий оптимизированные ядра и при этом позволяющий сохранить простоту кода.

Этот пост станет глубоким разбором того, как мы снизили задержки P95 конечной точки API с 5 до 0,3 секунды при помощи нишевого трюка computer science под названием «фильтр Блума».

Мы расскажем о том, почему конечная точка была медленной, о решениях, которые мы рассматривали для повышения её скорости, и о критериях выбора между ними. Также мы объясним, как всё это устроено внутри.