| What the logic behind config files being classes? |
|
Environment-based configuration values are handled differently, now. Since we were using classes (I'll get to why in a second) we had to find a different way to do it, so we went with .env files. This is a good way to help keep them completely separate per environment, as well as keep the security up a little since they should never be put in the repo. Here's a good article about why using .env files is a good thing.
When we first started discussing the configuration changes the idea was to decentralize the files themselves into more individual files that held only the settings needed for one part of the application. Since we were breaking away from the singleton pattern in the framework, we wanted to break away from a central, global config file, as much as possible. Each library would get the information that it needed only. As we talked more, using a single simple class was the simplest solution. It minimized the number of files that were needed, because you only ever had the single class, instead of having one for the environment and one global. It reduced file access time since we didn't have to scan different sets of folders for possible versions. Additionally, it made it so that the file could be loaded from anywhere the autoloader could find it, which might mean shared folder between applications, or in a module-like setup. Finally, it is as close to native PHP as we can get, without any additional abstractions, which is usually a good thing, also. For performance - I don't think we lose much, if any. PHP 7's handling of objects and arrays is stellar compared to the 5.x branches, which is where a lot of it's performance improvements come from. I can't think of a way off the top of my head, though, where you would be able to cache the config files together. And performance is something I'm trying very hard to keep similar to CI3. Due to "cleaner" architecture, there have been a little bit of slowdown, though we're still much closer to CI3 than any of the big-name frameworks. And it's something I'll take a deep-dive into at some point to see what other things I can find to boost performance. That said, running in a stock Homestead Improved virtual machine, under NGINX, I'm seeing 3 ms load times for the framework's welcome page. That's running on my 5 year old iMac, too. Running under MAMP Pro and Apache (which is very much not optimized) with xdebug off, I'm seeing around 9ms page load for the welcome page. Actually, just fired up my base CI3 install under Apache and am seeing around 12ms page load times. Might be a fluke for the evening, but we're actually running faster currently. Definitely not too worried about the performance, then.  EDIT: Holy cow. Just to try it out, I turned opcode caching on in PHP7 under my Apache install and tried again. PHP7 screams, guys - I'm getting 1ms -- or less! -- page loads to the welcome page. That's for both CI3 and CI4. |
| Welcome Guest, Not a member yet? Register Sign In |
