It doesn't matter how much memory PHP is using. As long as there is enough allocated.
PHP runs in a sandbox inside a webserver. The sandbox is allocated a chunk of memory for use by PHP, and when you hit that limit then PHP throws an out of memory exception. You have to either increase the limit in php.ini or change your code.
PHP scripts do not remain executing after a request is made. The script is terminated and the output buffer is sent to the browser. Your sample source code will only tell you how much memory was used for that HTTP request. The amount of memory used by PHP will change depending upon how many concurrent requests are made to the server, and what that server is configured to handle.
I think the default chunk of memory for PHP is 64MB, but I run mine at 2BG because I have command line cron jobs that are very memory hungry.
How much memory PHP uses is peak = 64MB * concurrent requests.
tl;dr it's not many include files vs one large file, it's the Drupal way.
Since you want to move onto Drupal, I'd suggest you go with it for real. Here is how Drupal works.
First, in Drupal, the only folder you can touch is sites/.
In sites/default, basically you only touch the settings.php file. Most of your time will be spent in sites/all/. In this folder, there are 2: themes and modules. Your theme will be where you guess it, and the modules (contributed, or yours) will be where you guess it too.
I won't write a tutorial about how to write themes. Basically, you have all your templates in your theme, and the modules use these templates. The big advantage is that you can override the templates used by other modules (which you shouldn't touch either) including the core ones.
Drupal separates modules by features. You, for your own website, usually separate your modules by business features.
I'm not going to write a tutorial about how to write modules, but here is how it basically works:
Your module needs a .module file. Let's say your module is foo. So you have in folder in sites/all/modules/foo/. In there, you have a file named foo.info (with basic information), and another file named foo.module. In the foo.module file, you have this kind of stuff:
function foo_menu() {
$items['bar'] = array(
'title' => 'Some title',
'page callback' => 'foo_answer_bar',
);
return $items;
}
function foo_answer_bar() {
return 'Baz';
}
The principle is to have functions starting with your module name, and ending with specific names, such as _menu. These functions are picked up by Drupal and it handles them. In this example, the returned array tells Drupal to handle the /bar URL, and to display what the foo_answer_bar returns, in the layout.
Anyway. I'm not going further in this example, but what I'm saying is that if you go with Drupal, go with the Drupal way. It will be a little hard in the beginning, but a lot less painful in the long way. Try to keep many small modules rather one big module. The same rules as OOP apply there (SOLID, KISS, DRY).
Best Answer
It won't give you any speed boost, nor bandwidth optimization, nor server memory usage.
What memory limit says is that when a script tries to use more memory, a error occurs. This is the only effect. PHP won't magically optimize memory if you reach the memory limit. If an object takes 16 bytes of memory, it will always take 16 bytes, no matter what is the actual memory limit and if it is reached or about to be reached.
Website speed depends on many factors such as the size of HTML, CSS, JavaScript and images, the number of requests per page required to load all the content, the time it takes to the code-behind to process the input and generate the output, etc. Memory limit has no effect on this.
Bandwidth usage depends on the size of HTML, CSS, JavaScript and images, the number of requests per page required to load all the content. Setting 2 MB or 200 MB as a limit won't change anything.
Memory usage for a given script won't change neither, since it depends on the number of objects and their respective size. If and only if the different scripts are randomly taking too much memory and the only response you have is to kill them, then it will have a positive impact on memory usage: instead of filling the memory, those bogus scripts will simply be stopped by a PHP error.
I highly doubt such case exists. When a script takes too much memory, what should a developer do is to inspect it with a profiler and to fix the parts which are allocating too much memory. Killing the instances which fill up memory is the weirdest way to "solve" the problem.
So why would anyone use the memory limit?
The memory limit can be useful in debug, to be sure that your application doesn't start to take too much memory.
This doesn't replace a profiler, but can be a good solution where you don't want so use more complex tools, but still want to be alerted when, one day, your app grows enough to fill 2, 50 or 200 MB of memory.
Note: PHP documentation is very clear on that:
Source: Description of core php.ini directives, emphasis mine.