As a SilverStripe user for multiple sites with a lot of content and multiple users I was eager to test the new stable SS-3 release.

I am disappointed.

I have already the experience that the backoffice / admin area in the 2x series are sometimes slow. But noticed that the new stable release, with a blank demo install, is slow and uses much more CPU, made me kinda upset.

I really appreciate your work, but making the admin area slow is realy a no go....

Banana do you have access to a profiler such as XHProf to track down what is slow? Is it server side or client side that is causing issues? When I fixed updated site loading time peaked from 0.8s for a 2.4 site to 6.2s (see my profile output at http://skitch.com/willrossi/897s9/xhprof-hierarchical-profiler-report) but this was due to SS_Cache not being able to save to the temp folder.

I had also the feeling the backend was kind of slow, which is particularly annoying since it locks the UI each time you load a page content (by the way, I think it should lock the UI only if the load time is above 1 second, it would be much more pleasant visually).
Then, I made some tests using xdebug. It seems that the slowest part of a page load is actually config::get. Which is very strange. When you look at the source code, there is a @todo saying that it needs to be heavily cached, and indeed, when you see what this bit of code is doing, I don't understand how a stable release can contain that type of code uncached.
I guess than when they will fix that, the UI will be much smoother!

Do you have similar experiences or is this just me ?

Chatting with Hamish (the author behind the config system) it has to perform the full lookup to maintain backwards compatibility. He's going to look at 3.1 to make the statics immutable which will allow stricter caching of Config::get().

thanks for your quick reply. I hope that will make things faster indeed, because according to my benchmarks, it seems to be quite a bottleneck.

Well I did not a performance test. But I noticed that the Browser process resources are going up to 100%. So it looks like heavy JS usage.

See the attached screenshot about the browser and system details.

EDIT:
I disabled all my FF plugins ( Firebug, Firecookie ) and it works much better, but still kinda slow...
The problem is, that the ppl who will use the CMS are not that geeky to get along with a "slow" system...

I don't know if this has anything to do with your issues, just thougt to point at this thread on the core dev group...

Thx, but it looks like a problem with Firebug. Disabling it makes it faster, but not really smooth...