Low Memory system.module
| Project: | Drupal |
| Version: | 6.14 |
| Component: | system.module |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
(See http://wtanaka.com/drupal/system-6 for more details)
This is a drop-in replacement for the system.module of Drupal 6.11 which makes Drupal 6 use less memory (on a stock OS install, I haven't tested with a PHP opcode cache/accelerator). On memory- and I/O- bound workloads, this reduction of memory seems to also translate into a speed and overall throughput improvement.
A test I ran in a development environment with a stock Drupal 6 installation (no custom modules enabled) suggested that I got:
* 2—4.4% reduction in average page load time
* 3% less memory
The patch preserves all "public" non-underscore functions inside the system.module namespace and also _system_theme_data() which is called from outside the system.module file despite starting with underscore.
I have tried my best to preserve exactly the semantics of the existing system.module with the exception of removing from the public namespace the rest of the underscore functions which are not called directly by core modules.
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| system-6.11-D6.patch | 143.11 KB | Ignored | None | None |
#1
This is actually similar to what has already been done to the menu module to decrease overhead: http://drupal.org/node/146172. it is definitely worth another look.
#2
Is this something that should be tagged with "Drupal 7" as well, or is it moot for that version?
#3
Please post a proper patch. This cannot be reviewed.
#4
Haven't we tried this before ? #345118: Performance: Split .module files by moving hooks
#5
Could you either explain what you mean by proper, or explain what in particular about this patch is not proper? That patch should apply cleanly against Drupal 6.11. I am attaching one for Drupal 6.14. The patch is a fairly mechanical application of this process. It removes all underscore functions from the global function name space with the exception of _system_theme_data() which at the time I created the patch was called directly by another core module in violation of what I remember the Drupal function naming conventions to be.
Given the nature of the unified diff file format, I do not believe that it is possible to make the file size of this patch significantly smaller, but I would love to hear suggestions as to how to do that if there are any! I believe this is just one of those cases where a semantically and conceptually compact change does not translate into a storage-space-compact unified diff.
A similar thing has been tried before with chx's split module, with the exception in that case where I think that module created one separate file per function.
I do have a suggestion for a way to review that this patch is a semi-mechanical translation of system.module:
1. Apply the patch, but keep a backup of the original system.module
2. Diff system.module.orig against each of the new files to make sure that function bodies have not changed
3. Manually review function headers in the newly created files
4. Manually review the function headers in the new system.module