Optimization of loading static data

A small question about how to optimize the loading of a large amount of static data into a PHP program.

There was a problem loading pre-calculated data into the program for finding the path between two points (no matter what). The problem arose so strongly that the loading of the calculated data began to occupy 90% of all subsequent calculations.
My data is a two-dimensional array consisting of 200 by 200 cells approximately.

I'm testing unserialize, json_decode

with letter keys
json_decode - 0.080sec
unserialize - 0.072sec
')
digital keys only
json_decode - 0.041 sec (170kb)
unserialize - 0.037 sec (500kb)

The route itself is searched for 0.0004-0.0012 sec :)
So you need to think of something else.

As an option - you can download data selectively. But for me this option did not fit (because under certain conditions it is necessary to use all the data).

And if you use the generated PHP-array with eval?

eval - 0.086sec
It is no good. :(

But what prevents me from uploading the generated PHP file instead of eval, which will be generated when the data changes?
In theory, it should load data faster.
As a result, the following code was born:

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

The test showed 0.023 sec (640kb).
It is 1.6 times faster than unserialize. True, it takes more space.
But this is a fixable matter - you can save it manually, for example, without saving keys, spaces, and transitions to the next line (which makes var_export).
The only negative is the static data structure.

eAccelerator

The second minus - we didn’t have another experiment - download.
include should convert 640 kb of text to code, and it takes 0.37 sec. Oh, how not great.

This is where eAccelerator comes to the rescue :) reducing the second and subsequent include files to 0.0001, which does not affect the resulting speed.

ps thanks to TiGR user for constructive criticism.