Performance concerns

Hi there! You are certainly not alone - and progress is indeed being made there however there are kinda two answers here that I would like to bring to light.

First is the future - the biggest issue I've seen is bottlenecking disk IO at the autoloader. The streams platform (streams structures and such) I believe are pretty solid from my profiling it over the past and caching things in memory. But there are a few layers (field types / addons in general at the service provider level) that demand loading classes during the boot cycle that slow things down. It's primarily disk IO. DO runs Pyro exceptionally well as do other high performance disk hosts. Our agency is with a small host in Houston that's great. AWS for example though will hound you for disk IOPS and you have to pay there the more you use and they throttle the shit out of you which is unfortunate.. But in the future - I have a large breaking change that will be introduced with 4.0 that loads things much lazier. As in nothing loads unless you tell it to. So addons will initialize their dependencies if any via a loader and if another addon needs loaded during the boot cycle you can do that from the outside. Otherwise keeping resources very slim. The second major break is related to routing. Pretty much all our CRUD generation is redundant and the routes as well. So we'll be doing a much smarter routing mechanism, again allowing you to override whenever you want easily. Both 4.0. Both breaking. Both addressing a TOP performance issue we have currently.

As far as the present - dev boxes are gonna suck most likely. I get like .5 to .7 page loads on my mack with SSD using MAMP. I do not have OPcache on which helps tremendously. We use OPCache on remote. Outside of that the biggest factor are quality disk. That said I've put up things on GoDaddy in the past that performed acceptably given it was on GoDaddy. You can also uninstall and delete some of the addons should you not use them. And lastly optimize your autoloader file with composer dump-autoload -o.

Hope this helps and let me know if you have any other questions!

You can also speed things up by not using features like "LIVE_ASSETS" and relying on Webpack or the likes instead. This is something we are also moving towards more as I get more acquainted with using it in a modular platform and the system progresses.

That's very helpful – thanks.

Any sense of when 4.0 might drop? Like, are these breaking changes under development, or still just being planned?

They are proven concepts I've hacked into the system but not made public on a feature branch (which I will clean up and change). Done so that I can see profiling differences and prove my hunches basically. I am also open to more ideas cause 4.0 is primarily centric on these changes (they're the only breaking things I have in queue).

That said there are a lot of badass features before 4.0 as well. But realistically end of 3rd quarter for 4.0. Maybe sooner as again I only have these things to put into it - and only have to major bump because of these changes in core. Everything else has been minor version bumps which I favor greatly. Hard to BC in loader changes though :-/

4.0, a new website, improved forum, improved docs, and better addon purchasing online are all part of this rollout I am working on.

Awesome – thanks for the prompt and thorough feedback!

I know this is an old thread, but: any word on when 4.0 might drop?

I was almost ready to pull the trigger on October CMS. But then I actually played around with developing for it, and...I kind of hate it. I'm looking for something developer-centric, and October seems really obsessed with point-and-click site building, .yaml configuration files instead of actual PHP code, and breaking source control with WordPress-style self-updates. Just let me write code, dammit!

@immersiontravis no hard date on 4.0 yet. I am trying to figure what else in the core foundations need to be broken to improve lol.

3.5 is in a pretty long RC right now because of tracking changes in deep relationships and honestly I've been tied up in a side project as well. As soon as that passes though 3.5 will solidify and I'll put more focus into 4.0 which.. off the top of my head I don't think will take much more. Will likely be backwards compatible too. But it's a lot of just thinking and making sure I don't need a 5.0 directly after the fact!

Our OTA updating system also has staged changes which plays into 4.0, new docs, site revamp. Those are some other aspects (ecosystem) that I will probably touch on before I release a final 4.0. Just because I'd like to start 4.0 with fresh documentation structure and addon / simple store system. Those will help make 4.0 more of a success than just 4.0 itself.