2009-11-18 34 views
13

Ho letto che quando si include un file php che utilizza percorsi assoluti ha un tempo di elaborazione più veloce rispetto ai percorsi relativi.percorsi relativi e assoluti php

Che cosa suggeriresti di usare?

include("includes/myscript.php"); 

o

include("/home/ftpuser/public_html/includes/myscript.php"); 

o anche

set_include_path("/home/ftpuser/public_html/includes"); 
include("myscript.php"); 

O è qualcosa che davvero non dovrei preoccupare?

risposta

15

Io di solito una costante, sia manualmente che in questo modo:

define('ROOT', dirname(__FILE__)); 

Poi fare

require ROOT . '/include/file.php'; 
+0

Se si ha 'ROOT', perché non' set_include_path (get_include_path(). PATH_SEPARATOR.ROOT) '? – chelmertz

+6

Perché in questo caso stai ancora cercando i percorsi di inclusione, in questo modo non è prevista alcuna ricerca. – Greg

+0

È una ricerca piuttosto semplice/veloce se la si posiziona prima: 'set_include_path (ROOT.PATH_SEPARATOR.get_include_path())'. Inoltre, la manutenibilità potrebbe essere compromessa se ci sono molti file da includere (ho elaborato la mia opinione più in una risposta). – chelmertz

1

quando non si utilizza un percorso assoluto, php tenta di trovare il file in tutti i percorsi di inclusione finché non trova una corrispondenza.

come molti percorsi di inclusione possono essere aggiunti come ti piace, quindi questo potrebbe, in rari casi, causare lo script di essere lento.
Se si includono molti file (ad esempio per inizializzare un framework) utilizzando percorsi assoluti potrebbe velocizzare lo script un po '...

Penso che potrebbe anche causare complicazioni quando lo stesso percorso relativo/nome file si verificano più volte sul filesystem, e quindi php seleziona la prima occorrenza, quando potresti aver bisogno di un'altra occorrenza

0

Sarebbe bene per te testare tutti i metodi controllando il tempo necessario per eseguirli, personalmente non me ne sono mai preoccupato e ho appena usato percorsi relativi.

Suppongo che i percorsi assoluti sarebbero leggermente più veloci, potrebbe valere la pena di chiedersi cosa succede in un errore, sputerà il percorso completo del file alla schermata degli utenti (ovviamente disattiva la segnalazione_errore) e ciò causerà un rischio per la sicurezza?

+1

Sputa i percorsi di file completi in entrambi i modi, per quanto ne so. È l'unico modo per essere sicuri di quale 'index.php' intendi. –

3

Decisamente non codificare i percorsi, come l'opzione due. Una buona alternativa è:

define('BASE_DIR', '/home/ftpuser/public_html/includes'); 
include(BASE_DIR . '/myscript.php'); 
include(BASE_DIR . '/myscript2.php'); 
include(BASE_DIR . '/myscript3.php'); 
include(BASE_DIR . '/myscript4.php'); 

Considerando probabilmente avrete qualche parte tra il 5 e il 50 include (sto cercando di indovinare), non mi sarebbe davvero preoccupare. Basta andare con percorsi relativi. La differenza di tempo inclusa non sarà nemmeno evidente. Se stai sviluppando una grande applicazione web e ne avremo centinaia, quella potrebbe essere un'altra storia ...

2

Tendo ad impostare le mie directory/librerie di inclusione impostando il percorso di inclusione sull'inizializzazione della mia app.

set_include_path("/home/ftpuser/public_html/includes"); 
include("myscript.php"); 

Il framework zend fa qualcosa di simile a caricare le classi della libreria.

8

Questo è il metodo migliore per il 99% dei casi:

include(dirname(__FILE__)."/includes/myscript.php"); 

Questo finisce per essere un percorso assoluto, il che significa che ignorerà include_path, che è una fonte nota di un gran numero di bug relativi alla mia esperienza ...

Per quanto riguarda le prestazioni, dubito che ci sia molta differenza tra percorsi assoluti e relativi. Questa è una sorta di micro ottimizzazione che non significa nulla a lungo termine. In genere ci saranno solo 2-3 cose in include_path a meno che non ne aggiungiate altri. I due colpevoli sono i ./ e il percorso verso il punto in cui è installato pear.

1

La cosa più importante è quello di organizzare i percorsi di inclusione in modo che il maggior numero di require/include -calls sono intrappolati nel primo percorso menzionato quando non è incluso un file tramite un percorso assoluto, in primo luogo.

Fare affidamento sull'inclusione di tutto tramite un percorso assoluto è difficile da mantenere perché cambiare il percorso della libreria significa modificare singolarmente tutti quei file che fanno riferimento ad esso invece di modificare il percorso di inclusione in un unico punto.

7

Ho scritto un semplice script di test di velocità utilizzando microtime(true). Mette alla prova i metodi tra cui seguenti cinque con un milione di iterazioni:

// Absolute path. 
include('/home/ftpuser/public_html/includes/myscript.php'); 

// Predefined path. 
define('PATH', '/home/ftpuser/public_html/includes/'); 
include(PATH . 'myscript.php'); 

// Relative path. 
include('myscript.php'); 

// Using set_include_path(). 
set_include_path('/home/ftpuser/public_html/includes/'); 
include('myscript.php'); 

// Superglobal path. 
include(dirname(__FILE__) . '/myscript.php'); 


che ha dato i seguenti risultati (in secondi):

 
    Absolute path:   263.222 
    Predefined path:   263.545 
    Relative path:   301.214 
    Using set_include_path(): 302.396 
    Superglobal path:   269.631 


La mia opinione sulla base di questi risultati è quello di utilizzare un percorso predefinito, perché è il più veloce sorpassato solo da un percorso assoluto. Tuttavia, un percorso assoluto ha lo svantaggio di dover essere modificato in ogni file quando è necessaria una modifica.

Spero che questo abbia aiutato. :)

P.S.
define e set_include_path() sono stati utilizzati una sola volta durante l'esecuzione dello script (si trovano all'esterno del ciclo).

Problemi correlati