Оптимизация загрузки статических данных

Небольшой хабратопик про то, каким образом можно оптимизировать загрузку большого количества статических данных в программу на PHP.

Встала проблема загрузки заранее посчитанных данных в программу поиска пути между двумя точками (не важно какую). Проблема встала настолько сильно, что загрузка просчитанных данных стала занимать 90% всех последующих расчётов.
Мои данные — двухмерный массив, состоящий из 200 на 200 ячеек примерно.

Тестирую unserialize, json_decode

с буквенными ключами
json_decode — 0.080sec
unserialize — 0.072sec

только цифровые ключи
json_decode — 0.041 sec (170kb)
unserialize — 0.037 sec (500kb)

Сам маршрут ищется за 0.0004-0.0012 sec :)
Значит, надо ещё что-нибудь придумать.

Как вариант — можно загружать данные выборочно. Но для меня этот вариант не подошел (потому что при некоторых условиях необходимо использование всех данных).

А если использовать сгенеренный PHP-array с помощью eval?

eval — 0.086sec
Никуда не годится. :(

Но что мне мешает вместо eval подгружать сгенеренный PHP файл, который будет генериться при изменении данных?
По идее он должен загружать данные быстрее.
В результате родился такой код:

define("PREDEFINED_PATH","path.inc");

include_once(PREDEFINED_PATH);

function create(){
  $data=array();

  // Генерация 2D массива $data
  // ...

  file_put_contents(PREDEFINED_PATH,"<?function return_path(){return ".var_export($data,TRUE).";}?>");

}

function use(){
  //использование

  //$path=serialize($p);
  //$path=json_decode($p);
  $path=return_path();
}


// Файл path.inc выглядит
<?function return_path(){return array(1=>array(1=>array(1=>2,2=>12,3=>...)));}?>

// Функция return_path возвращает готовый массив

Тест показал — 0.023 sec (640kb).
Это 1.6 раз быстрее, чем unserialize. Правда, занимает больше пространства.
Но это дело поправимое — можно сохранять в ручную, например, не сохраняя ключи, пробелы и переходы на следующую строку (что делает var_export).
Единственный минус — статичная структура данных.

eAccelerator

Второй минус — мы не провели ещё один эксперимент — загрузка.
include должен преобразовать 640 kb текста в код, и занимает это 0.37 sec. Ух как не здорово.

Здесь нам на помощь приходит eAccelerator :) снижая вторую и последующие include файла до 0.0001, что на результирующую скорость не влияет.

p.s. спасибо юзеру TiGR за конструктивную критику.