I'm checking this. The performance of CPU rendering seems to be slower which also impacts CPU+GPU rendering.

The performance of CPU+GPU rendering appears to be slower in 2.91 and more sensitive to the chosen tile size. The slowdown seems to come from the tiles rendered and denoised by the CPU. It seems significant enough to warrant further investigation.

Please keep in mind that the very first time rendering with CUDA in an new version takes longer because it has to prepare the render kernels. The render times do fluctuate quite a bit between different runs in the same version, so a proper comparison would have to profile several renders.

The following quick measurements have been made using a GeForce GTX 1080 Ti and i7-6850K.

Tile size: 63x64

Tile size: 256x256

@Robert Guetzkow (rjg) Thanks for looking into it, hope it will eventually be resolved!
The time measurements I presented weren't the first render after starting the program, but the second/third, anyway I'll do some other tests just to be sure and write them down here.
Not sure if you need to know it, but my CPU is a i9-7900X.

Did some other tests with the same setup (64x64), same results, this time at the second/fourth render they actually increased from last time, from 2 to 10 seconds.

WITHOUT OPTIX
2nd render: 02:41:37
3rd render: 02:44:59

WITH OPTIX
4th render: 04:32:20
5th render: 04:32:61

I noticed that the project uses adaptive sampling, which may or may not be relevant to the issue at hand.

@Brecht Van Lommel (brecht) @Jeroen Bakker (jbakker) Have you seen this performance issue during CPU rendering before? I'm a bit hesitant to confirm performance related issues, but this does seem like a regression.

Just thought I'd add:

Rendering with CPU (Ryzen 9 3900X) with tile size 63x64 with OptiX disabled on Linux-5.8.0-3 Debian, these are my results:

These results aren't significantly different, like the results show by @Robert Guetzkow (rjg) and @slwk1d (Slowwkidd), so I thought I may not be experiencing the issue because I'm running Linux. So I retested on Windows (Windows-10-10.0.19041-SP0 64 Bits) with the same CPU and same render settings and these are the results:

Based on the small number of tests done so far, it seems the issue doesn't affect Zen 2 CPUs (at the least). Suggesting part of this "regression" may be caused by a change that negatively affects other CPU architectures. Both @Robert Guetzkow (rjg) and @slwk1d (Slowwkidd) are using "older" Intel CPUs. However, this is just speculation.

I'm not sure if the following can influence render times according to Blender version (since it is also something related to CPU work).

I have noticed that apparently Righ s. and Left s meshes fall into some OpenSubdiv 2.8+ still present bug/limitation with Subdivision Surf. Modifier. When you open the .blend file it takes a long time to load. The same happens when you initialize the render. In both cases there is a single threaded process working at 100%. I think it is something related to what has already been described here:
https://developer.blender.org/T58191

If you remove the single face that "closes" the volume in the Righ s. and Left s. the problem I describe seems to go away. Here only Righ s. object in 2.79 .blend file

Edit:
Intel i7-3770 here. Ryzen users also have the performance problem that I describe with OpenSubdiv, right?
This is even more evident with this for example:
https://developer.blender.org/T58191#945339

So my intervention in this report is because I'm not sure if OpenSubdiv performance in those cases may have varied a bit between those versions of Blender.

@YAFU (YAFU) Thanks for pointing out a problem related to subsurf, it's true that regardless of the blender version the file opening and render initializing were slow, but then why in 2.90 the same file renders faster? Might be as @Alaska (Alaska) suggested a regression due to specific CPU architectures?

Bug reports require as simple as possible .blend files, the intent here is not for Blender developers or triagers to analyze production scenes, we expect the reporter to make an effort to identify what specifically in the .blend file is causing the problem.

Remove as many objects, materials, modifiers, as possible, disable settings, set a low number of samples, and figure out what exactly is causing the issue.

Sorry for not diving a little bit deeper before, I think I actually found out: the regression in 2.91 regards renders with a large resolution.

Here's is a very simple scene:

At 1000x1000 pixels, the scene renders both in 2.90 and 2.91 in around 1 second.
At 3000x3000 pixels, in 2.90 it renders in ~16 seconds, in 2.91 in ~48 seconds.

Important to note that the regression is present in CPU, GPU and CPU+GPU rendering, so it doesn't seem to be connected specifically to CPU issues.

That would be T82591 then.

Is this the same as T82591: Performance regression when rendering at very high resolution?