Удивительно медленные операции

https://gregoryszorc.com/blog/2021/04/06/surprisingly-slow/
Понравилась статья о том, что на наших мощнейших компьютерах, некоторые
операции могут быть на удивление медленными.

* Environment detection in build system
  Множество раз замечал что, действительно, сама сборка софта может
  занимать в разы меньше времени чем отработка autoconf ./configure
  скрипта. На работе когда я перевёл Си проект, в котором прилично вещей
  автоматически определяется, на redo, то все эти цели стали
  распараллеливаться и конфигурирование плюс сборка занимают пару секунд
* Про fork/exec overhead и file close на Windows системе не в курсе, ибо
  не работаю с этим миром в принципе
* То что можно в разы ускорить сборку софта просто не заставляя выводить
  это всё в терминал -- давно знал. Медленные терминалы это ещё какая
  реальность, особенно часто они почему-то являются default-ными в
  системе. Ну и то, что сам по себе системный вызов write() имеет вполне
  себе ощутимый вес -- об этом тоже не забываю и вовсю стараюсь
  буферизировать данные в памяти перед его вызовом
* С изменением частоты процессора не особо знаком. Уже давно все
  ноутбуки держу в режиме постоянного числодробления и полного
  отключения всех этих фич по управлению питанием и частотами -- и
  стабильность и простота. Но да, помню что читал про забавный факт о
  том что если заряжать Apple ноутбуки не с той стороны -- то будет
  падение производительности. И особенно на текущем ноутбуке я замечал
  что запустив какую-то ресурсоёмкую задачу можно поднять частоту,
  соответственно и производительность и снизить время выполнения многих
  команд, из-за которых процессор даже не попытается ускориться. У меня
  в фоне distributed.net числодробящий клиент висит с idprio 31
  приоритетом поэтому. Экономия это конечно хорошо, но всему должна быть
  мера
* Время запуска интерпретаторов Python, Ruby, Node.js -- оно просто
  громадное! Именно только из-за этого времени я множество скриптов и
  программ переписывал на другом языке. Запуск долгоживущего сервера --
  не критично сколько будет запускаться, но если это часто вызываемая
  утилита (даже просто для ведения заметок), то жутко угнетает видимая
  задержка
* Раздел про I/O я не очень понял. Ну точнее я прекрасно понимаю почему
  fsync() может быть достаточно медленной операцией -- для меня это не
  вызывает удивления. Видимо, потому что любил читать и понимать
  устройства файловых систем. Ну а то что из-за NVMe действительно
  кардинально может меняться подход к I/O -- это да, факт. С NVMe I/O
  может перестать быть бутылочным горлышком, чем оно де-факто всюду и
  везде всегда являлось
* И отсюда, соответственно, появляется и тот факт, что сжатие данных
  может наоборот вести к тому, что CPU будет узким местом, а не дисковая
  подсистема или сеть. Благо, у меня чёткое осознание что нужно
  проверять где и в чём затык, а не слепо что-то там пытаться сжимать.
  Иногда сжатие может помочь с уменьшением кол-ва round-trip-ов, из-за
  уменьшенного кол-ва пакетов, тем самым сокращая задержки, хотя
  запросто и ни капли не увеличивая пропускной способности
* Тема про то, что заранее скомпилированные пакеты/бинари могут не иметь
  кучу оптимизаций под современные процессоры -- мне тоже хорошо
  знакома. Когда я пользовался FreeBSD на AMD K6-2 233MHz, то точно
  помню перекомпилирование всей системы/ядра/софта с нужным -march
  позволяло на 10% поднимать производительность в целом. Ещё один довод
  чтобы собирать софт из исходников. Хотя я скорее поверю и в то, что в
  общем случае для yet another home computer или yet another server все
  эти оптимизации не существенно чем будут помогать. А CPU-hungry софт и
  так следит за тем чтобы собираться с нужными оптимизациями
* Тема про то, что банальное разбиение на строки может быть более долгой
  операцией чем целые алгоритмы создающие diff на основе этого -- мне
  тоже понятна. И, честно, когда в Go приходится что-то делать над
  каждым байтом/символом просто итерируясь -- скрепя сердцем, закрываю
  на это глаза, слепо надеясь (зная что это наверняка не так) что
  компилятор мог бы это и прооптимизировать

Но вообще это отличные примеры того что нужно всегда всё мерить, а не
делать предположения, если неизвестно устройство/особенности. Без устали
повторяют про то, что надо оптимизировать нечто только после измерений и
понимания что действительно такое то место является бутылочным горлышком.