I've done some tests on a 60M flv and found that there's no difference
in memory consumption with these three approaches:
public function test() {
Kohana::close_buffers(false);
$file = "/home/bharat/basketball.flv";
if ($fd = fopen($file, "rb")) {
while (true) {
$bits = fread($fd, 65535);
if (strlen($bits) == 0) {
break;
}
print $bits;
set_time_limit(30);
}
fclose($fd);
}
Kohana_Log::add("error","test: " . print_r(array(memory_get_peak_usage(true),memory_get_peak_usage(false)),1));
}
public function test2() {
Kohana::close_buffers(false);
$file = "/home/bharat/basketball.flv";
$fd = fopen($file, "rb");
fpassthru($fd);
fclose($fd);
Kohana_Log::add("error","test2: " . print_r(array(memory_get_peak_usage(true),memory_get_peak_usage(false)),1));
}
public function test3() {
Kohana::close_buffers(false);
$file = "/home/bharat/basketball.flv";
readfile($file);
Kohana_Log::add("error","test3: " . print_r(array(memory_get_peak_usage(true),memory_get_peak_usage(false)),1));
}
mostly issues around uninitialized variables, calling non-static
functions in a static context, calling Session functions directly
instead of on its singleton, passing non-variables by reference, and
subclasses not using the same interface as the parent class.
1) Controller::$input is gone -- use Input::instance() now
2) Handle new 'database.<default>.connection.params' parameter
3) Handle new 'cache.<default>.prefix' parameter
Kohana makes this type of transition fairly straightforward in that
all controllers/helpers/etc are still located in the cascading
filesystem without any extra effort, except that I've temporarily
added a hack to force modules/gallery into the module path.
Rename what's left of "core" to be "application" so that it conforms
more closely to the Kohana standard (basically, just
application/config/config.php which is the minimal thing that you need
in the application directory)
There's still considerable work left to be done here.
