2010-02-24 12 views
15

mają system buforowania plików dla biblioteki php 5, której często używam. po otrzymaniu żądania sprawdzam, czy nie ma pliku buforowanego, jeśli istnieje, to go wyrenderuję i zakończę.Czy plik_get_contents jest wolniejszy niż zawiera?

$contents = file_get_contents(self::_cacheFile()); 
echo $contents; 
exit();  

mam zrobić file_get_contents zamiast po prostu to z powodu buforowane pliki xml z nieznośnego

`<?xml version="1.0"?>` 

czy istnieje lepszy sposób, aby pociągnąć w moich plikach cache bez shorttags wypalania?

+2

I potem ludzie mówią, że nie ma problemu z krótkimi tagami ... –

+0

tak, nienawidzę shortagów, wydaje się zbyt łatwe do wywołania php przez przypadek jak e powyższy przykład. –

+0

To krzyczy na pamięć binarną. Co powiesz na skompresowanie plików do przechowywania i rozpakowanie ich do pamięci? Lub, jeśli buforujesz całą odpowiedź, wysyłając spakowaną kopię? To pozwoliłoby uniknąć krótkich tagów. Osobiście wyłączam krótkie tagi za każdym razem, gdy dostaję się do php.ini. – TheJacobTaylor

Odpowiedz

10

Jeśli wszystko, co chcesz zrobić, to wypisać zawartość pliku, powinieneś używać readfile(). To jest szybsze i mniej intensywnie niż pamięć file_get_contents()

31

Od include oceni zawartość plików, np. uruchom przez interpreter PHP, a także użyj include_path, aby znaleźć pliki, powiedziałbym, że include jest wolniejszy. file_get_contents potraktuje zawartość pliku jako ciąg. Mniejsze obciążenie, większa prędkość.

Z manual page:

file_get_contents() jest preferowanym sposobem odczytać zawartość pliku do łańcucha. Będzie korzystać z technik mapowania pamięci, jeśli jest obsługiwany przez system operacyjny w celu zwiększenia wydajności.

Jednakże, jeśli jesteś po wyprowadzanie pliku, zamiast się go na sznurku, readfile() jest nawet odrobinę szybciej niż file_get_contents. Zważywszy, że include "będzie również wyprowadzać dowolne treści nie pochodzące z PHP, prawdopodobnie bardziej prawdopodobne jest to, że jesteś po, jak sądzę.

Revised odniesienia na moim komputerze stacjonarnym:

$start1 = microtime(1); 
for($i=0; $i<100000; $i++) { 
    include 'log.txt'; 
} 
$end1 = microtime(1) - $start1; 

i

$start2 = microtime(1); 
for($i=0; $i<100000; $i++) { 
    echo file_get_contents('log.txt'); 
} 
$end2 = microtime(1) - $start2; 

i

$start3 = microtime(1); 
for($i=0; $i<100000; $i++) { 
    readfile('log.txt'); 
} 
$end3 = microtime(1) - $start3; 

Wynik

echo PHP_EOL, $end1, // 137.577358961 
    PHP_EOL, $end2, // 136.229552984 
    PHP_EOL, $end3; // 136.849179029 
11

file_get_contents i include nie robi to samo:

  • file_get_contents odczytuje zawartość pliku i zwraca go jako ciąg
  • include wykona zawartość pliku.

O szybkości, bez pamięci podręcznej rozkazu, przypuszczam file_get_contents teoretycznie powinna być szybsza, jak ma to mniej obliczeń (bez kompilacji/wykonanie kodu).

Najważniejsze jest jednak to, co próbujesz zrobić: jeśli chcesz tylko przeczytać plik, powinieneś użyć file_get_contents.

+0

Ale marginalnie, ponieważ w plikach nie ma kodu ... –

10

Nic nie przebije (dobrze wykonanego) testu porównawczego (który jest trudniejszy niż się wydaje, może coś przeoczyć). Ponieważ oba są wykonane w tych samych warunkach, powinny służyć jako miarka.

test.txt jest 12kB, 876 linii pliku tekstowego:

[email protected]:~$ ls -la test.txt ; wc -l test.txt 
-rw-r--r-- 1 vinko vinko 12264 2010-02-24 19:08 test.txt 
876 test.txt 

file_get_contents.php:

[email protected]:~$ more file_get_contents.php 
<?php 
echo file_get_contents("test.txt"); 
?> 

include.php

[email protected]:~$ more include.php 
<?php 
include("test.txt"); 
?> 

readfile.php

[email protected]:~$ more readfile.php 
<?php 
readfile("test.txt"); 
?> 

Więc razem, gdy wykonanie 10 tysięcy iteracji każda:

[email protected]:~$ time for i in `seq 10000`; do php file_get_contents.php >/dev/null; done 

real 3m57.895s 
user 2m35.380s 
sys  1m15.080s 

[email protected]:~$ time for i in `seq 10000`; do php include.php >/dev/null; done 

real 3m57.919s 
user 2m37.040s 
sys  1m16.780s 

[email protected]:~$ time for i in `seq 10000`; do php readfile.php >/dev/null; done 
real 3m57.620s 
user 2m38.400s 
sys  1m14.100s 

Wniosek: Wszystkie trzy są praktycznie równoważne do 12 Kb plików tekstowych w PHP 5.2.4 z Suhosin Patch.

+1

, który powinien być "echo $ contents;" bez '()'. Również 'readfile' zapisuje bezpośrednio w buforze wyjściowym i zwraca liczbę całkowitą, więc nie ma potrzeby powtarzania tego. Po prostu wywołaj "readfile". Nie potrzebujesz również wywołań "exit". – Gordon

+0

@Gordon: Dzięki, zmieniłem scenariusze i przetestowałem. Jeszcze bardziej wyrównany :) –

1

file_get_contents będzie najszybszy sposób, aby pobrać plik pamięci podręcznej na kilka powodów:

  1. wykonuje żadnego przetwarzania na dane to obciążeń (parsowania kodu PHP, obsługi nowych linii itp)
  2. Wykorzystuje zoptymalizowane techniki ładowania plików tak szybko, jak to możliwe (pliki odwzorowane w pamięci dla jednego).
5

dzięki za cynk, dla tych, którzy są ciekawi

readfile(); 
<!-- dynamic page rendered in 0.133193016052 seconds.--> 
<!-- static page rendered in 0.00292587280273 seconds.--> 

vs.

file_get_contents(); 
<!-- dynamic page rendered in 0.133193016052 seconds.--> 
<!-- static page rendered in 0.00303602218628 seconds.--> 

vs.

include(); 
<!-- dynamic page rendered in 0.133193016052 seconds.--> 
<!-- static page rendered in 0.00348496437073 seconds.--> 
+5

Pojedyncze wykonanie nie jest wystarczające dla benchmarku, musisz wielokrotnie iterować –

+1

10% dłuższy czas odpowiedzi dla strony statycznej. Co się dzieje, gdy włączysz pamięć podręczną kodu opcode? +1 do badań. – TheJacobTaylor

Powiązane problemy