[dev] Re: [cvs] commit: horde/lib/MIME Part.php

[Michael M Slusarz]

Quoting Jan Schneider <jan at horde.org>:

| Zitat von Michael M Slusarz <slusarz at bigworm.colorado.edu>:
|
| > slusarz     2003/07/08 12:38:43 PDT
| >
| >   Modified files:
| >     lib/MIME             Part.php
| >   Log:
| >   Bug: 1206
| >   Submitted by: edv at via-berlin.de
| >   Splitting these lines up reportedly drastically reduces memory usage.
|
| Huh, how that?

OK, I was playing around with memory_get_usage() in PHP 4.3.2, but that
function only seems to be concerned with the total amount of memory
allocated to variables, not the total/max amount of memory PHP is using in
total.

Thus, as far as allocation of memory to variables is concerned, here's what
I found.  For a 2,000,000 byte file (exactly) this code (#1):
$contents = file_get_contents('testfile');
$encoded_contents = base64_encode($contents);
$contents = chunk_split($encoded_contents, 76, "\n");
print memory_get_usage();

Outputs "5385384"

This code (#2):
$contents = file_get_contents('testfile');
$contents = chunk_split(base64_encode($contents), 76, "\n");

Outputs "2718424"

This code (#3):
$contents = chunk_split(base64_encode(file_get_contents('testfile')), 76,
"\n");

Outputs "2718400"

So it would seem that the old way (#2) we did this was more efficient than
the new way (#3).  But I'm wondering, although the old way may be more
efficient from a variable/memory perspective, it might be less efficient in
memory usage in that it requires more memory to be allocated for PHP to
_process_ the data.  That seems to be the only way to explain why the user
said that #2 did not work for him (out of memory error), but #1 is fine.

AHA!  I have found it.  Didn't realize before I wrote this that the
'memusage' call existed (at least on Linux).  So, here are the statistics
of the heap memory allocation for each PHP execution in total (done with
'memusage php test.php'):

#1 heap total: 7798552, heap peak: 7741803, stack peak: 18544
#2 heap total: 7798436, heap peak: 7741503, stack peak: 18448
#3 heap total: 7798244, heap peak: 5741055, stack peak: 18368

So in terms of real memory allocated, #1 and #2 are essentially identical
(more of what we would expect).

Anybody else (who knows more about this stuff than I surely know) want to
comment on this?

michael

______________________________________________
Michael Slusarz [slusarz at bigworm.colorado.edu]
The University of Colorado at Boulder