Gwenouille, here’s my results with the file you posted;
1:12 Blender2.45
1:42 Blender2.49b
I feel the same way, It may not seem like a big difference but a 40% increase in time could have a big impact on a larger scene or movie project.
Right before posting I tested the file in 2.5 rev.22956
Time: 2:09, 79% increase from 2.45:(
try apply the modifier and triangulate, then benchmark 2.45 and 2.49 and see what the speeds like ignoring the over zealous triangulation. (and without recompiling)
@ Campbell:
I’ve applied the modifier on Suzanne, selected all faces and turned them to tris with CTRL+T.
Here is the file (Suzanne with applied modifier and Tris is on Layer 2).
Here is what I get:
2.45:
2.49b:
They do find the same number of faces (all tris in that case) but that doesn’t solve the render-time issue.
I won’t have the opportunity to test a special build with that function commented: I am not at home and won’t go through the trouble of installing scons, python etc…
Now, for all to be clear, I am not saying “here is something wrong”, just trying to understand what is going on…
Hi, I am a bit surprised not to find more echo with this issue…
Can anyone explain why the latest versions are so much slower on such a simple scene ?
I for one am very interested in what’s going on.
I knew I wasn’t crazy!
I’ve been having this feeling that blender is getting slower and slower, but never took the time to try some simple tests. Thank you PhilB.
Trust me, I nearly always render animations and to me every second counts. So I am quite eager to see this investigated and fixed asap, hopefully even for 2.49 as that is what most people are going to work with for quite some time. But I have no idea how, some hints from someone working with the rendering pipeline that knows where to look would be helpful. On that note, thanks Campbell for posting suggestions to diagnose this.
Make sure that you set the number of threads manually in 2.49, otherwise it might use a different number than with 2.45.
Martin
Rendering shadows after reflection/refraction had a speed regression after glossy reflection/refraction were added, and this was never fixed. Then it was moved to the todo tracker, but it’s really a bug, so I moved it back now.
A proper fix requires a review of the whole system, breaking compatibility, but it could at least revert to what it did before. The problem with that though is that it gives poor results in other cases, which were there before too and are fixed by this change, at the cost of a general performance regression. The relevant bug report is here:
http://projects.blender.org/tracker/?func=detail&atid=125&aid=8358&group_id=9
Oh good news. I opened this regression bug such a long time ago.
Good to hear it wasn’t completely forgotten 
I’m testing jaguarandi’s raytrace optimizations right now… it’s so fast it made me forget about this previous regression. 
nothings really changed, maybe people like it that way, ?
Hi, I’m responsible for the particular issue in those above tests, so you can direct your lynch mobs at me 
It’s a tricky thing that mostly only shows up under those circumstances (sharp shadows in refractions or reflections). Like Brecht said, it’s a tradeoff - the changes that made it that way are due to internal code changes to reduce the reliance on Full OSA as a method for smoothing edges of sharp shadows.
Prior to this, Full OSA was enabled for every material, as long as raytracing was switched on. So in a scene, where you were only using raytracing for one material (like a character’s eyes) and shadow maps for everything else, every material would still be over-sampled. So rather than shading just once, all complex procedural textures, SSS, translucency, z transparency would be sampled multiple times, equal to the OSA value (5 times, 8 times, etc), just in the off chance it might end up having a raytraced shadow fall upon it, regardless of whether that was possible or not, which was quite wasteful. This old behaviour also made it much less efficient to do adaptive sampling, which brings a large performance increase when rendering normal solid objects with raytraced shadows (sharp or soft).
Anyway, the changes to the code did bring up this performance regression under this circumstance. I’ve just committed a little tweak that fixes it in this particular case, without hopefully any major quality loss either.
As brecht said, the entire shading system (especially regarding ray tracing) really needs a huge makeover, it’s a lot of ancient hacks and fixes piled on top of each other, and things can be done much better. I’d personally much rather work on that than spend too much time on patching the current one, but oh well 
PS. Gwenouille - that scene is a nasty test case, it’s pretty much a worst-case scenario for the octree. You can speed up the rendering of that scene by about 10x by increasing the octree size to 512 or scaling down the floor plane. The new BVH should be much less susceptible to these kinds of problems.
I don’t like the idea of realism seekers getting ripped with a performance regression to favor those whose computers are too old to do a lot of soft shadows (which is what is pretty much required in most cases), which I assume it would probably affect you at Promotion studios because of your use of soft shadows.
Well then you don’t need to worry, because that’s not what is happening here.
Also I did note this
As brecht said, the entire shading system (especially regarding ray tracing) really needs a huge makeover, it’s a lot of ancient hacks and fixes piled on top of each other, and things can be done much better. I’d personally much rather work on that than spend too much time on patching the current one, but oh well
Shouldn’t Jaguarandi’s work provide a good springboard to actually do such a makeover for the raytracing part of the shading system? I assume it would help.
Jaguarandi’s code makes ray casts faster, Dont think it would have any affect on shading design.
even if blender still had no raytracing shading would need refactoring.