• Насколько медленны iostreams?

      Потоки ввода-вывода в стандартной библиотеке C++ просты в использовании, типобезопасны, устойчивы к утечке ресурсов, и позволяют простую обработку ошибок. Однако, за ними закрепилась репутация «медленных». Этому есть несколько причин, таких как широкое использование динамической аллокации и виртуальных функций. Вообще, потоки — одна из самых древних частей стандартной библиотеки (они начали использоваться примерно в 1988 году), и многие решения в них сейчас воспринимаются как «спорные». Тем не менее, они широко используются, особенно когда надо написать какую-то простую программу, работающую с текстовыми данными.

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

      Сегодня в комментариях у посту возникло обсуждение о медленности iostreams. В частности, freopen пишет
      Забавно смотреть на ваши оптимизации, расположенные по соседству со считыванием через cin :)

      а aesamson даёт такую рекомендацию
      Можно заменить на getchar_unlocked() для *nix или getchar() для всех остальных.
      getchar_unlocked > getchar > scanf > cin, где ">" означает быстрее.


      В этом посте я развею и подтвержу некоторые мифы и дам пару рекомендаций.
      Читать дальше →
    • Сравнение программ сжатия в применении к передаче больших объёмов данных

      Всё началось с простой задачи: скачать по 100-мегабитной сети большой объём данных с помощью rsync. Возник вопрос, можно ли ускорить этот процесс. Утилита top показала, что на сервере-источнике шифрование занимает не более 10 процентов процессора, поэтому было решено что можно попробовать сжатие данных. Тогда мне было неясно, будет ли хватать производительности процессора для упаковки данных с необходимой скоростью, поэтому была выставлена самая маленькая степень сжатия, а именно использовался флаг --compress-level=1 для rsync. Оказалось, что загрузка процессора не превысила 65%, то есть производительности процессора хватило, при этом скорость скачивания данных несколько повысилась.

      После этого возник вопрос о анализе применимости распространённых программ сжатия
      для передачи данных по сети.
      Читать дальше →