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:
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
|
@ -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. */
|
||||
|
|
Loading…
Reference in New Issue