154: Multi-layer API to handle common cases in minimal loaded code, Eliminate minikernel.php - Composr CMS feature tracker

ID	Project	Category	View Status	Date Submitted	Last Update

154	Composr	core	public	2010-04-10 18:35	2013-09-27 14:49

Reporter	Chris Graham	Assigned To	Chris Graham
Priority	normal	Severity	feature
Status	resolved	Resolution	fixed

Summary	154: Multi-layer API to handle common cases in minimal loaded code, Eliminate minikernel.php
Description	minikernel.php is an architectural mistake because it means maintaining a second compatibility API. It would make more sense, and be achievable, if the main API just looked at flags to determine what cannot be done. Also, for performance, we need a single Composr kernel that we can then design to have multiple levels of implementation detail; average loads would use the minimal implementation that meant including very few code files and less overall code. This means things would load a lot faster on servers without a good opcode cache (one of the biggest slow-downs in Composr on some servers is simply loading up PHP code files, not executing it). Example cases where code can be pulled out into levels rarely included: - The database API is bigger than it needs to be - most page loads don't even need writes, and if they do (such as bumping view counts) we can code our writes in direct SQL so that less API is needed. - get_param in most cases is just returning a plain string. - There's quite a lot in sources/support.php that is certainly not needed on average page loads. - Even something like 'get_bot_type' is almost a null-op in most cases (due to it detecting what is NOT a bot in just a few lines of code) - so we can make functions like these stubs, loading only the full implementation if really needed. - Certain API operations will not be needed at all if we have the self-learning cache fully implemented. Particular large parts of the language API would hardly ever need to be called. So it makes sense to split up this API so that usually most of it is not loaded. Another good way of thinking of this is that if we can have an algorithm that 'learns' common cases (or if we hard-code them) we can avoid full implementations in most cases. - Optimise for GET requests, so POST implementations not normally needed. Generally go through all commonly loaded code and think "is this needed in most cases - can we make it learned and/or make it slip-stream on 99% of cases and usually never load the PHP code for the advanced implementation". Maybe set an ambitious target - say 4000 lines of code max to be loaded up a news entry screen. Probably not achievable, but a challenge. Also alter the bootstrap code so that the ajax load flags aren't needed. A leaner core API should allow that. Alter the request/output state modification functions so they handle all PHP super-globals so you can enter/exit the Composr environment cleanly (allows better inclusion capabilities between scripts, as well as meta-code).
Additional Information	Success metrics (not guaranteed, but nice targets to check to after work is done, to avoid stopping short): - Only 4k of code loaded - Tiny bootstrap time; test simple script that just says 'hello' after Composr has bootstrapped
Tags	Risk: Breaking upgrade bootstraper , Risk: Core rearchitecting , Type: Performance
Attach Tags	(Separate by ",")

Time estimation (hours)	18
Sponsorship open

Date Added	Member	Amount Sponsored

Chris Graham 2013-09-27 14:49 administrator ~1793	Somewhat implemented. A lot more optimisation has happened in line with the ideas discussed here. However at the same time, this was definitely a bit over-optimistic. The Code Book will now contain a clear description of all the core responsibilities the Composr code has and the reasoning for it: it's dozens of really important non-negotiable things that do lead to thousands of lines of basic framework. At the same time, we're effectively optimising paths through them.

Date Modified	Username	Field	Change
2016-06-08 00:14	Chris Graham	Tag Renamed	Risk of breaking upgrade bootstraper => Risk: Breaking upgrade bootstraper
2016-06-08 00:15	Chris Graham	Tag Renamed	Core rearchitecting => Risk: Core rearchitecting