I created a big smoke simulation and wanted the smoke to have rainbow colours. One of the later frames (600) using a single colour took me about 2 minutes to render while using the "rainbow material" it took me about 16 minutes.
Can someone explain to me where this big increase in render time comes from because I can't get my head around it but I want to understand it better.
My relatively uninformed guess is that it is likely caused by Cycles shader optimization, or in this case the lack thereof.
Textureless volumes are probably assumed to have constant color or density, and as such optimized to render disregarding variations across the smoke depth.
This probably saves considerable processing power by skipping color or density checks at every depth step, as the rendering rays traverse the volumetric shader.
It may also be the case that by using heat as input into your shader, Cycles requires more data that either consumes more (system or GPU) memory, or requires uploading CPU computed data from the smoke simulation into the video memory (when GPU rendering using CUDA or OpenCL) at every frame, which is generally a slow process.
After a simple test I'd go with the theory of shader optimization. Just having a simple color input like texture coordinates on a basic volume shader almost duplicates render time.
Constant color about 15 seconds
Simple color variation about 30 seconds
I guess a smoke simulation with varying density and heat based colors will only worsen the calculation.
heatattribute is very badly documented but as far as I could research it (mostly blender stackexchange answers as well) it ranges from -1 to 1 where -1 is the "coldest" part of the smoke (therefore the one that is in the scene the longest time) and 1 is the "hottest" (the part being emitted freshly). $\endgroup$ – SUBHUMAN Sep 4 '19 at 18:46