#258 - Optimisation
-
By Chris Graham
- Added
- 13 views
| Identifier | #258 |
|---|---|
| Issue type | Feature request or suggestion |
| Title | Optimisation |
| Status | Closed (rejected) |
| Tags |
Type: Performance (custom) |
| Handling member | Chris Graham |
| Addon | core |
| Description | Update cache clearing API functions to work with bitmasks, instead of lots of separate functions.
Like: clear_caches(CACHE_ALL); clear_caches(CACHE_TEMPLATES|CACHE_IMAGES); This makes it easier to keep track of where we are clearing caches, so it is easier to convince ourselves on correct behaviour when the below is implemented... --- Optimise out some Tempcode variables: 1) Ones that align perfectly with standard caching parameters, like 'theme' or 'language'. 2) Ones that are only dynamic in the sense that the Admin might edit something. All language variables count here (e.g. '{!FOO}'). We just make sure that when the admins edits, a full Tempcode cache flush happens. The Tempcode compiler will need some way of identifying such variables and evaluating them instantly and saving them into the cached template. Any directives wholly contingent on optimised-out variables can be unwrapped. The challenge is to move Tempcode output as close to echo'ing a static string as possible. --- Maybe make lack of any "keep_*" a standard cache parameter, so that people without them get a Tempcode stream that has {$PAGE_LINK} optimised out. Motivation: we always should have the common case as the fastest case, not pander to complexity in the main code path. --- Maybe make usergroups a standard cache parameter, and optimised out all permission checks. But only on sites without member permissions and where there aren't large numbers of permissive groups. --- (this kind of repeats some of the above) Consider 'inlining' more Tempcode processing that otherwise would require an evaluate_conventional_variable call. Particularly: - IF_EMPTY/IF_NON_EMPTY (as simple and common logic) - $LANG/$THEME (as they are implicit inside the template cache directory anyway, so absolutely cleanly cachable) More aggressive caching if enabled (the problem is, automatic cache flushing can't work on it): - language references - $IMG - ... --- The Tempcode cache can be slow to empty. An optimisation might be to dynamically create a new table, and switch them around via renaming, letting the old one empty on a register_shutdown initiated query. --- Have a self-learning cache for: - config option loading - permission loading - theme image loading - what blocks are needed to reduce initial quantity loaded from database. --- Get rid of manual Tempcode type conversions by letting PHP do it itself - change _true/_false to PHP strval equiv (1 and blank?) - use toString from PHP5, dropping PHP4 support --- Probably mentioned elsewhere already, but make get_timezoned_date return a Tempcode symbol, to make context sensitive dates cache-safe. |
| Steps to reproduce | |
| Funded? | No |
The system will post a comment when this issue is modified (e.g., status changes). To be notified of this, click "Enable comment notifications".
Comments