Arjen van Bochoven - 17 November 2008 12:01 PM
@narkaT: You assume the second parameter of set_header() is a single char, but that is nowhere enforced, people can send in an empty string if they want. You should also set the type of the second var (which should be a boolean).
thats right, I should have done some “cleaning” before posting the code 
I’ve edited the above code.
Arjen van Bochoven - 17 November 2008 12:01 PM
edit: Make sure you use the {memory_usage} psuedo variable in your view to measure memory usage, otherwise you get the cached value.
I measured the memory usage directly in the extended output class using memory_get_peak_usage.
very “hacky” although.
I were confused that in my benchmark there where no difference between the memory consumptions,
even though I used the same php-function as CI to get the memory usage.
so I used the method with {memory_usage} you suggested.
I managed to detect the problem an cut down the memory usage drastically 
my previous benchmarks reported the same memory usage because I measured the usage
before calling the _display-function.
So the call to the _display-function was the cause of the large memory usage.
passing the output by reference solved that issue for both, my strpos approach and
your serialize approach.
I’ve done some benchmaking after optimizing the scripts.
both used str_repeat for generating the data (I’ll leave out the non cached results).
one with 7Mb and one with 50Kb
7Mb
build in preg_match():
21.38MB - 0.0360 s
serialize():
7.4MB - 0.0239 s
strpos():
7.41MB - 0.0352 s
50Kb
build in preg_match():
0.53MB - 0.0041 s
serialize():
0.45MB - 0.0044 s
strpos():
0.46MB - 0.0045 s
serialize is clearly the memory-friendliest solution and when caching big chunks of
data its also the fastest
