printf замедляет мою программу

Вы можете сохранить свои строки в буфере и выводить их в файл (или консоль) в конце или периодически, когда ваш буфер заполнен.

При выводе на консоль прокрутка обычно убийца.

Если вы используете printf () в консоли, это обычно очень медленно. Я не уверен, почему, но я считаю, что он не вернется, пока консоль графически не покажет выведенную строку. Кроме того, вы не можете использовать mmap () в stdout.

Запись в файл должна выполняться намного быстрее (но все же на порядки медленнее, чем вычисление хэша, все операции ввода-вывода выполняются медленно).

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

1. Ввод / вывод всегда медленный по сравнению с прямое вычисление. В системе есть ждать, пока будет больше компонентов доступны для их использования. Это то должен ждать ответа прежде, чем он сможет продолжить. Наоборот если это просто вычисления, то это только действительно перемещающие данные между Регистры RAM и CPU.

2. Я не тестировал это, но может быть быстрее добавить ваши хэши в строку, а затем просто напечатать строку в конце. Хотя, если вы используете C, а не C ++, это может оказаться проблемой!

Боюсь, что 3 и 4 выше меня.

Поскольку ввод-вывод всегда намного медленнее, чем вычисление ЦП, вы можете сохранить сначала все значения в максимально быстром вводе-выводе. Так что используйте RAM, если у вас достаточно, используйте Files, если нет, но это намного медленнее, чем RAM.

Теперь распечатку значений можно производить позже или параллельно другим потоком. Таким образом, вычислительному потоку (-ам), возможно, не придется ждать, пока не вернется printf.

Теперь распечатку значений можно выполнять впоследствии или параллельно другим потоком. Таким образом, вычислительному потоку (-ам), возможно, не придется ждать, пока не вернется printf.

Теперь распечатку значений можно выполнять впоследствии или параллельно другим потоком. Таким образом, вычислительному потоку (-ам) может не потребоваться ждать, пока не вернется printf.

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

Кроме того, кто будет их читать? Нет смысла печатать их все в удобочитаемом формате, если никому не нужно их все читать.

1. Почему бы не создавать строки по запросу, а не на этапе построения? Нет смысла выводить 40 экранов данных за одну секунду, как вы вообще можете их прочитать? Почему бы не создать вывод по мере необходимости и просто отобразить последний экран полностью, а затем по мере необходимости его прокручивает пользователь ???

2. Почему бы не использовать sprintf для печати в строку, а затем построить объединенную строку всех результатов в памяти и напечатать в конце?

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

4. Консольный вывод по определению медленно, создание хеша - это манипулирование всего несколькими байтами памяти. Вывод в консоль должен проходить через многие уровни операционной системы, который будет иметь код для обработки блокировки потоков / процессов и т. д., когда он в конечном итоге попадет в драйвер дисплея, который может быть устройством со скоростью 9600 бод! или большой растровый дисплей, простые функции, такие как прокрутка экрана, могут включать в себя манипулирование мегабайтами памяти.

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

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

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

Отредактировано: Что касается 2,3, то это выше меня. Для 4, Я не знаком с Sun, но знаю о Solaris и кое-что испортил, Там может быть опция ядра для использования виртуального tty .. Я признаю, что давно уже не возился с конфиги ядра и его перекомпиляция. Таким образом, у меня может не хватить памяти на это, у меня есть корень с опциями, которые нужно увидеть.

user@host:/usr/src/linux $ make; make menuconfig **OR kconfig if from X**

Это запустит меню ядра, нужно покопаться, чтобы увидеть раздел настроек видео под поддеревом устройств. .

Отредактировано: но есть настройка, которую вы добавили в ядро, добавив файл в файловую систему proc (если такая вещь существует), или, возможно, в ядро ​​передали переключатель, что-то вроде этого (это образный и не подразумевает, что он действительно существует), fastio

Надеюсь, это поможет, С наилучшими пожеланиями, Том.