Low Memory system.module

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

The specific conditions of the test I ran are documented on http://wtanaka.com/drupal/system-6

No opcode cache was installed, I'm specifically interested in hearing feedback if this makes things worse, better, or does not change anything with an opcode cache installed.

The patch (also available at above url) has been updated for 6.15

crea: Feel free (beyond the fact that you're already free based on the terms of the GPL) to use this patched module in your Pressflow or in anything else as long as you abide by the GPL terms.

I am not sure if I am supposed to change the status back myself now that I answered the questions. I will err on the side of assuming that I am supposed to.

crea, these are great suggestions. I didn't mean you can patch your installations, I meant you can add the patch to (your?) Pressman project without needing to consult me.

However, it's not clear to me that you should do that. Like you say, I don't know of results of tests with an opcode cache enabled, so it might not be a win in that case. Presumably if it's a win without an opcode cache and a wash with one, you might consider including it, but if it's a win in one case and a loss in the other, you probably wouldn't want to include it.

If Pressman is interested in things like this, you might want to point them at this issue trail. Perhaps they have the time to spare and an stable opcode cache setup where they can run the opcode test that so many people seem to want to see the results of?