[Перевод] Как ускорить сложение и вычитание при помощи 2^51

Помните, как долго выполняется сложение на бумаге? ¹¹ ¹ 6876 + 3406 ------ 10282 Начиная с единиц, мы складываем 6 + 6 = 12, записываем 2 и переносим 1. Затем пошагово двигаемся влево, пока складываемые разряды не закончатся. При реализации сложения больших чисел (например, от 2 64 и выше) обычно пишут код, похожий на этот алгоритм. Любопытно здесь то, что существует простой трюк, позволяющий существенно ускорить этот процесс на современных CPU. Но сначала я задам вопрос: почему сложение столбиком мы начинаем с самого младшего разряда? Почему бы не начать слева? Дело, разумеется, в переносе. Мы не можем точно знать, каким будет текущий разряд числа, пока не выполним все сложения справа от этого разряда.

https://habr.com/ru/articles/915800/

#сложение #перенос #оптимизация_производительности #вычитание

Зачем нужен fillfactor в PostgreSQL

Привет, Хабр! Один параметр PostgreSQL может похоронить вашу производительность, если вы о нём забудете — это fillfactor . Почему однократная настройка числа приводит к неожиданным page split , bloat и мучительному откату запросов? Давайте разбираться.

https://habr.com/ru/companies/otus/articles/905882/

#базы_данных #fillfactor #Deadlocks #блокировки_в_субд #субд #Оптимизация_производительности

PostgreSQL: грабли, на которые мы наступаем… снова

СУБД PostgreSQL является одной из самых популярных реляционных баз данных с открытым исходным кодом, и благодаря почти 40-летней истории развития она является отличным выбором для приложений любого размера. Но многие начинающие администраторы и разработчики совершают одни и те же ошибки при работе с этой СУБД. В этой статье мы рассмотрим некоторые из них.

https://habr.com/ru/companies/otus/articles/902942/

#postgresql #sql #Btree_индексы #Оптимизация_производительности #индексы #Утечка_соединений #субд #Неоптимизированные_SQLзапросы #vacuum

[Перевод] На страже производительности Spring Boot приложений: Профилирование и оптимизация

Spring Boot широко используется для создания масштабируемых и эффективных Java‑приложений. Однако по мере усложнения или масштабирования вашего приложения могут начать проявляться узкие места производительности, что приводит к замедлению времени отклика и увеличению потребления ресурсов. Выявление и устранение этих узких мест является важнейшей составляющей процесса оптимизации производительности вашего приложения, особенно в производственных средах. В этой статье мы подробно рассмотрим, как можно оптимизировать производительность Spring Boot приложений, используя базовые методы профилирования и тюнинга. Особое внимание будет уделено таким аспектам, как профилирование процессора и памяти, оптимизация сборки мусора и тюнинг виртуальной машины Java (JVM).

https://habr.com/ru/companies/otus/articles/892716/

#java #spring #spring_boot #производительность #JVM #оптимизация_производительности

Оптимизация React-приложений: Используем useTransition, useDeferredValue и useOptimistic для плавного UI

Сделайте интерфейс React-приложения более отзывчивым и плавным с помощью хуков useTransition , useDeferredValue и useOptimistic . Управляйте приоритетами рендеринга, избегайте подвисаний при работе с большими данными и реализуйте оптимистичные обновления для мгновенной реакции интерфейса. Практические примеры и полезные советы ждут вас! 🚀

https://habr.com/ru/articles/870748/

#react #react_hooks #оптимизация_производительности #плавный_интерфейс #javascript #usetransition #usedeferredvalue #useOptimistic #вебразработка #производительность_UI

Софт на диете: как мы в DCAP OCR разгоняли

Привет! Мы в «СёрчИнформ» 20 лет создаем софт для защиты информации и постоянно его оптимизируем. Например, последовательно работаем над ресурсоемкостью продуктов (низкая нагрузка на оборудование – важное преимущество для заказчиков), и придумали в этом направлении много удачных (не только наше мнение) решений. Запускаем серию постов об этом. Сегодня – о том, как пересобрали архитектуру OCR в нашей DCAP-системе (файловом аудиторе), чтобы ускорить анализ изображений, не перегружая серверы и пользовательские ПК.

https://habr.com/ru/companies/searchinform/articles/842514/

#OCR #DCAP #сёрчинформ #fileauditor #распознавание_изображений #ресурсоемкость #оптимизация_производительности

[Перевод] Почему MMAP не лучший выход

Доступ к файлам через отображение-в-память ( mmap ) — это способность некоторых операционных систем отобразить содержимое какого-либо файла в адресное пространство программы. Сама программа получает доступ к содержимому файла через указатели, как если бы сам файл был бы целиком загружен в оперативную память. Операционная система прозрачно загружает части файла в оперативную память, и автоматически выгружает их, когда памяти не хватает. MMAP захватила умы программистов СУБД на многие десятилетия, как альтернатива буферу данных. И вот здесь следует отметить, что в mmap имеются серьёзные проблемы с корректностью и скоростью работы с данными в современных СУБД. В реальности, некоторые известные СУБД сперва использовали mmap для работы с "больше-чем-вмещается-в-память" базами данных, но вскоре обнаружили эти скрытые ограничения, которые принудили их к самостоятельному управлению файловым вводом/выводом, после заметных трат на инженерные исследования. В этом смысле mmap и СУБД подобны сочетанию кофе и острой пищи: неудачное сочетание, которое не очевидно, пока сам не попробуешь. Покуда разработчики по прежнему пытаются использовать mmap в новых СУБД, мы написали эту статью, чтобы предупредить остальных, что mmap это не подходящая замена привычному буферу. Далее мы обсудим основные недостатки mmap , а также покажем явные ограничения производительности, которые мы обнаружили в наших экспериментах. На основании этих находок мы поделимся рецептами, когда разработчикам СУБД следует избегать mmap для реализации файлового ввода/вывода.

https://habr.com/ru/articles/820591/

#СУБД #оптимизация_производительности #mmap

[Перевод] Челлендж по обработке миллиарда строк на Go: от 1 минуты 45 секунд до 4 секунд

Пару недель назад я прочитал о запавшем мне в душу челлендже по обработке миллиарда строк , поэтому захотел решить его на Go . Я немного опоздал, соревнования проводились в январе. И на Java. Меня не особо интересует Java, зато давно интересует оптимизация кода на Go . Этот челлендж был очень прост: обработать текстовый файл названий метеорологических станций и температур, и для каждой станции вывести минимальное, среднее и максимальное значение. Чтобы упростить задачу, было ещё несколько ограничений , однако я проигнорировал те, что относятся только к Java.

https://habr.com/ru/articles/798215/

#go #оптимизация_производительности #работа_с_файлами #высокая_производительность #челлендж