19:47
Мне только спросить
Программа должна была через примерно равные промежутки времени (около 200 микросекунд) делать определённые действия и выдавать на выходе файл с данными. Однако когда данные из файла представляли в виде графика, было чётко видно, что при переходе от этапа 1 к этапу 2 наблюдается дыра (пауза) около 1 миллисекунды. Эта дыра нас не устраивала.
Начальство предложило функции, в которые были зашиты этапы 1 и 2 (алгоритмы), развернуть и вставить в основную функцию. Я крутил и так и сяк, пытался какие-то предварительные действия вынести в основную функцию, не убирая полностью внутренние, но дыра не пропадала. Однако полностью запихивать функции этапа 1 и 2 в основную было плохой идеей, потому что эти функции использовались ещё в шести местах, кроме того, они вызвали ещё десять других функций, и, если дело было во времени вызова, то исключить те вызовы уже не удалось бы никак. Тогда у меня возникла невероятная догадка -- единственные две операции (кроме непосредственно вызова функций), которые могли занимать время (из оставшихся) -- это вывод сообщения в окошечко на экране и вывод отладочного сообщения в лог-файл (не в файл с данными, а в файл с отладочными сообщениями).
Я закомментировал вывод на экран и в лог-файл и -- о чудо -- пауза пропала! Дальнейшие изыскания выявили, что дело было в обращении к жёсткому диску (в файл с данными данные пишутся один раз -- в конце). Не думал, что лично столкнусь с ситуацией, когда в лог-файл писать некогда. Хотя меня когда-то предупреждали, что такое бывает. В таких случаях лог-файл пишут в память, а потом иногда сбрасывают на диск.
Начальство предложило функции, в которые были зашиты этапы 1 и 2 (алгоритмы), развернуть и вставить в основную функцию. Я крутил и так и сяк, пытался какие-то предварительные действия вынести в основную функцию, не убирая полностью внутренние, но дыра не пропадала. Однако полностью запихивать функции этапа 1 и 2 в основную было плохой идеей, потому что эти функции использовались ещё в шести местах, кроме того, они вызвали ещё десять других функций, и, если дело было во времени вызова, то исключить те вызовы уже не удалось бы никак. Тогда у меня возникла невероятная догадка -- единственные две операции (кроме непосредственно вызова функций), которые могли занимать время (из оставшихся) -- это вывод сообщения в окошечко на экране и вывод отладочного сообщения в лог-файл (не в файл с данными, а в файл с отладочными сообщениями).
Я закомментировал вывод на экран и в лог-файл и -- о чудо -- пауза пропала! Дальнейшие изыскания выявили, что дело было в обращении к жёсткому диску (в файл с данными данные пишутся один раз -- в конце). Не думал, что лично столкнусь с ситуацией, когда в лог-файл писать некогда. Хотя меня когда-то предупреждали, что такое бывает. В таких случаях лог-файл пишут в память, а потом иногда сбрасывают на диск.
06.10.2014 в 20:15
07.10.2014 в 05:27
Самое ужасное, что он при этом пишет за секунду в лог несколько мегабайт текста.
07.10.2014 в 05:48
07.10.2014 в 10:44
07.10.2014 в 12:55
Foul thing, да, а ты проводил в тестах очистку буфера после каждой записи?
z4s00, при времени проведения операций (измерений) 200 мкс, 1 мс это целых пять точек!
07.10.2014 в 14:42
07.10.2014 в 17:27
07.10.2014 в 17:40
07.10.2014 в 17:59
На примере fstream, манипулятор flush:
www.cplusplus.com/reference/ostream/flush-free/
07.10.2014 в 18:05
07.10.2014 в 18:08
07.10.2014 в 18:29
07.10.2014 в 18:48
Но fwrite все равно быстрее: 0.1 мкс без очистки буфера и 1.9 мкс с очисткой через fflush().
Это, кстати, в билдере. В студии у меня другие цифры получились.
07.10.2014 в 18:51
Что в студии другие -- это из-за разных реализаций стандартных библиотек.