Fix T76767: Cycles performance regression with CLI renders

When picking a small tile size when doing a CLI render will
yield many status updates being printed to the console
causing a slowdown in the render process. 2.79 with the
same amount of tiles did not have this slowdown.

The reason for this turned out to be a debugging aid added
in rBd2757d149bf2 which disabled buffering for stdout which
on windows caused every single character being printed to the
console to try to obtain a mutex, and worse the thread being
put to sleep when this mutex was unavailable leading to poor
performance.

This patch changes the behaviour by only disabling the
buffering in debug builds.

CLI render of the default cube with 16x16 tiles at 1080p

2.83 : 37.57s
now  : 17.03s

note: this only affected CLI renders, renders from the UI
do not report this kind of information and had no such
slowdown.
This commit is contained in:
Ray molenkamp 2020-06-17 09:26:49 -06:00
parent 9bfd78ae14
commit e590526af6
Notes: blender-bot 2023-02-14 05:59:31 +01:00
Referenced by issue #77348, Blender LTS: Maintenance Task 2.83
Referenced by issue #76767, Slow Cycles CLI render with proper tile sizes
1 changed files with 5 additions and 1 deletions

View File

@ -248,8 +248,12 @@ int main(int argc,
/* Unbuffered stdout makes stdout and stderr better synchronized, and helps
* when stepping through code in a debugger (prints are immediately
* visible). */
* visible). However disabling buffering causes lock contention on windows
* see T76767 for detais, since this is a debugging aid, we do not enable
* the unbuffered behavior for release builds. */
#ifndef NDEBUG
setvbuf(stdout, NULL, _IONBF, 0);
#endif
#ifdef WIN32
/* We delay loading of openmp so we can set the policy here. */