事前に計算されたデータをプログラムにロードして、2つのポイント間のパスを見つける際に問題が発生しました（どちらでも）。 問題が非常に強く発生したため、計算されたデータの読み込みが後続のすべての計算の90％を占め始めました。
私のデータは、およそ200〜200個のセルで構成される2次元配列です。
私はunserialize、json_decodeをテストしています
文字キー付き
json_decode-0.080秒
シリアライズ解除-0.072秒
デジタルキーのみ
json_decode-0.041秒（170kb）
シリアル化解除-0.037秒（500kb）
ルート自体が0.0004〜0.0012秒検索されます:)
つまり、他のことを考え出す必要があります。
または、データを選択してダウンロードできます。 しかし、私にとってこのオプションは適合しませんでした（特定の条件下ではすべてのデータを使用する必要があるため）。
そして、evalを使用して生成されたPHP配列を使用する場合は？
評価-0.086秒
ダメです :(
しかし、データが変更されたときに生成される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秒（640kb）が示されました。
これは、非シリアル化よりも1.6倍高速です。 確かに、それはより多くのスペースを占有します。
ただし、これは修正可能な問題です。たとえば、キー、スペース、および次の行（var_exportを作成する）への移行を保存せずに、手動で保存できます。
唯一のマイナスは、静的データ構造です。
eAccelerator
2番目のマイナス-私たちは別の実験を行っていません-読み込み。
includeは、640 kbのテキストをコードに変換する必要があり、0.37秒かかります。 うわー、それは素晴らしいことではありません。
ここでeAcceleratorが私たちの助けになります:) 2番目以降のインクルードファイルを0.0001に減らしますが、結果の速度には影響しません。
psユーザーTiGR 、建設的な批判に感謝します。