Been experimenting with Cycles lately and have noticed some things with the principled shader. It seems to create some things incorrectly compared to using the Mix shader with the different bdrfs route.
Like grass for example, the principled shader doesn’t have a translucent parameter. You need to use the translucent bdrf to create backfacing color when creating mat for foliage.
The curious question I wanna ask is the principled shader designed to render faster if you use it compared to using the Mix shader with the different bdrfs? I would think that using the seperate bdrfs should save more render time since you are only using the ones required for the materials you want to setup rather than a full shader like the principled shader.
The Principled BDSF node is slower then the Diffuse node, but faster then most of the other material nodes, partially because it has a lot less to calculate in terms of input sockets, whether they’re connected to another node or not.
How many input and output sockets, alongside operation complexity, all factor into performance.
For example, Translucent BDSF & Transparent BDSF nodes use transparency, which can be pretty performance draining if you use too much of it.
Mix Shader [shaders] on their own to my knowledge aren’t too performance draining, however, when joined with more complex shaders, such as one of those transparency nodes, they can become just as performance deadly.
If you wish for some performance tips for ultimate performance. The one main thing I would is to bake anything and everything you can. Materials, textures, physics, bone and shape-key animations, etc. The less Blender has to calculate in real-time, the higher the performance speed will be.
Ups… i did some simple comparision yesterday and forgot to post … only just a few samples not even HD and both setups in one material (maybe different without unused nodes)… did some renders with repeated almost same time for each… left principeled… right simple shaders… NOT the same result… so it depends: do a quick render and fiddle with some parameters or make a special setup and optimise look or performance… you spend time in one or the other but there are already differences in time to detect… (depends on setup and maybe also on geomtry)… In the end: have to decide for oneself and the case.
The principled shader makes a lot of shortcut for you.
it’s simpler to use, not sure it will be faster than a manual setup but in general it’s still worth using it.
Let’s say you want to make a plastic material with 0.5 roughness. You can mix a diffuse and glossy node.
How you’ll handle fresnel attenuation (given that the material is rough the fresnel effect will be less intense) ? And/or will you use fresnel at all ?
If you know how to answer these question properly, then you may not need principled and you may have slightly faster results. If not, the principled answer these for you.
Yes, this shader is tricky , the correct way of using it is to use the Add shader node, that you can use on top of the principled or another setup.
If you use it correctly there is not much differences. Let say you keep SSS slider at 0 then principled will act as if there is no SSS at all, you won’t have any slowdown.
But of course for some cases you may need to build your own material from basic building blocs. Keep it mind that is more error prone and the principled help you to mix Diffuse, Glossy, SSS… in a correct way.
Yes, but Diffuse is only one component of a material. If you want to do PBR shading, or shader that behave correctly, then you need to add a Glossy component, driven by fresnel.
And chances are that it will be nearly as fast as using the principled by default.
It’s the same, it’s just than with cycles both these tend to slow down renders. That’s noticeable when you have a lot of layers of transparency.
Because it’s raytracing, when the ray hit the surface of an opaque object it will bounce. and after a few bounces on objects, then reaching a light source it can tell the pixel color value for one sample.
Now let say you add 20 transparent layers in front of that object, the ray should go between these 20 layers, then hit the object, bounce and eventually know the color of the pixel.
Sound simple and not that hard to compute, but this tend to slowdown renders. probably because it’s not 100% transparent to exacly know the color of each layer some extra bounces are needed on top of the traversal of each layers…
Because Eevee works differently , you don’t have these slowdowns.
… only just a few samples not even HD and both setups in one material (maybe different without unused nodes)… did some renders with repeated almost same time for each… left principeled… right simple shaders… NOT the same result… so it depends: do a quick render and fiddle with some parameters or make a special setup and optimise look or performance… you spend time in one or the other 
but there are already differences in time to detect… (depends on setup and maybe also on geomtry)… In the end: have to decide for oneself and the case.