Never heard of DCR. What is it?
Dead Code Reduction.
In compiled languages unused code isn't included in the executable if the compiler is worth a damn, but in interpreted languages we have no such auto-optimization... but even in compiled languages where that exists, there are times when the executable is called that the whole program has to be loaded, even if it isn't used that time the user runs it. This isn't generally a problem for client side apps, but with server stuff well, there's a reason we tend to run them as services.
In source-delivered interpreted languages though, we take a huge hit for unused branches in our code. We need the branches there, but loading a branch unused is a waste.
Thus most of what goes into my squire.lib.php either dynamically loads content as needed using smaller wrappers -- see Lang:: and Bomb:: -- or otherwise only loads what the Request needs.
It's a problem I see in a lot of heavily "object based" code, is that they are often less code in total, but they run more code every blasted time they start because EVERYTHING a class does is loaded, whether it's used or not. Whilst that's oft unavoidable on classes like Database, It's a disaster when done with templates.
Like I know a lot of people would say to include /template/default/forms.template.php ... but what if we're building a system that doesn't have a form? Or take the extras sections as an example. Should we load its template methods even if we're not using them?
We get into user control, are we really going to load everything you can do to a user -- even when the separations should be there for security (like not allowing "User" object to do anything but the "Read" and "Update" parts of CRUD by crapping it all into one giant object, for commands only the admin should have access to?
Languages though is the best example. For the most part if a "section" of our languages is used there are likely some values to be loaded, but that doesn't mean we should waste time -- and system memory -- loading every Joe-blasted regionalization string every blasted page-load.
Which I've seen people do as well.. Just because I need Lang::get('@hashFailure_login') doesn't mean I need to load every single login error's content text.
Which is why one of the changes in the upcoming code is to break all the different HTTP error codes out into their own separate /lang/language/httpErrors/###.txt files. Smaller less frequently used files can also lead to memory reductions that play better with caching models at the filesystem cache and PHP opcode cache levels.
Hence a DCR pass in languages like PHP where the programs don't have to be monolithic oft involves figuring out what's used on every pass, and what is not. It means more includes and more separate loads, but it can reduce the memory footprint in a way that results in better/faster caching and faster execution times.
Whilst writing the functionality first pass it's often easy to forget this, hence it helps to 1) build the architecture with this in mind, and 2) make a few passes through the whole code to think about what's used every page load, what's used frequently, and what you need to scream at yourself "Oi, leave it out gimboid!"
I've added a few things to the to-do list for this after the base admin panel and the CRUD for users is implemented. (hoping to start that tonight).
In no particular order:
template stacks -- a master Template object where the template functions are registered as anonymous as multiple arrays of function. This will allow extensions/modules to hook themselves into the template stream wherever we leave "hooks" for it. "printf" style strings may also be supported for the people who dislike working with functions for everything, though I prefer to "keep it in my pants" on that with non-content stuff given the gross inefficiencies of complex string processing.
I'll provide it, but likely will use it minimally "out of box" for the same reason I prefer comma delimits, and think that high-string processing overhead templating in PHP --- smarty/handlebars/whatever -- or even just double-quoted strings with variables {} in them is mind-numbingly dumbass trash I would rarely if ever allow in my code.
I'm sure there's an exception somewhere, but...process stacks -- I've already implemented this for just "extras" but it should be expanded to make adding third party mods easier. @benanamen you'll be happy to know extras is not opt-in by setting them with Extras::add, instead of being opt-out with Settings::set
Dynamic user data -- another table for users with a many to one of data the admin will be able to choose/add/customize. The typical id/user_id/name/value table style.
profile modal -- rather than completely pollute the main menu, move admin controls, moderation controls, and other such user actions to their own modal.
Right now though I'm working on my milestone copier, which is about as close to version control as I ever get since again, I find most version control junk. I'd rather have people send me date-coded files of their changes, than waste my life dicking round with asshat broken slow bullshit like GIT. Again I'd sooner eat a bullet than deal with GIT or anything like it given the headaches, counter-intuitive interface, and just plain rubbish they seem to be.
I can hand assemble RCA 1802 machine language, but I can't wrap my head around the benefits of GIT and its kine. I think it's mix of issues.
1) disgust from how I've watched so many "project managers" do everything EXCEPT manage projects by using Github so they can spew bullshit bingo in meetings and then play Farmville all day instead of doing actual work.
2) A mental block much akin to how I can't understand/do "visual programming". I can't use RAD's either, gets in my damned way too much and doesn't match my workflow.
3) I've watched it screw codebases because people are lazy in commenting their commits, at which point why the hell bother. At least if you have an
ACTUAL FLIPPING PERSON reviewing changes, approving and merging new code with the responsibility of checking both intent and efficiency, you have a chain of both liability and can keep a project on track.
But no, apparently ^C^V into a new .txt with a timestamp in the filename with text describing the how/what/why of the changes, and having an actual person riding herd on the development team -- aka MANAGING THE FLIPPING PROJECT -- is "too hard" these days.
That said, I am very interested to see what you did to reduce the code size so much. I'm all about smaller code, but not at the cost of memory, performance, or code clarity. Though those three are often akin to
the old joke about "soon", "cheap", and "well written"; pick only two.