I nomi delle variabili influiscono sulle prestazioni dei siti Web?


10

I nomi delle variabili influiscono sulle prestazioni del sito Web? So che questo sarà un numero molto basso, ma qualcuno può ancora fornire i motivi per non scegliere un nome di variabile lungo in termini di prestazioni?


2
Chiarisci la tua domanda: dov'è questa variabile e in che lingua è scritta?
Luke Graham,

16
Non dovresti mai, MAI scegliere nomi di variabili brevi e illogici se il tuo ragionamento è (discutibile) delle prestazioni. Il codice sorgente è lì per altre persone per leggerlo, non per soddisfare i computer e i loro microscopici guadagni di prestazioni.
Michael JV,

sto usando PHP ..
Avinash,

2
... E possiedi xpertdeveloper.com?
Jim G.

3
Ciao Avinash puoi spiegare nella tua domanda la tua logica per pensare che questo potrebbe essere il caso?

Risposte:


17

qualcuno può fornire i motivi per non scegliere un nome di variabile lungo in termini di prestazioni?

Michael ha coperto la risposta (ovvero No) ma i nomi delle variabili influiscono sulle prestazioni del programmatore . Se porti un nuovo sviluppatore o qualcuno che non ha familiarità con il codice, avere nomi di variabili lunghi e / o confusi può distrarre e rallentare il processo di comprensione.

In generale, si desidera utilizzare nomi di variabili brevi e descrittivi perché sono più facili da leggere. Immagina se devi ignorare il tuo codice per 10 anni e poi capire di nuovo tutto. Preferiresti leggere "getInput" o "getInputFromUserWhoInputsStringOrElseInformReaderOfError"? (esagerazione ovviamente: P)

Ci sono volte, tuttavia, in cui avere un nome leggermente più lungo può essere utile. Ad esempio, getBirthdayInput () sarebbe molto più descrittivo di getInput (). Vuoi semplificare fino a un certo punto, ma l'eccessiva semplificazione può anche essere problematica.


6
per leggere nomi lunghi è meglio, se trovi "getInputFromUserWhoInputsStringOrElseInformReaderOfError" non hai bisogno di leggere la documentazione su cosa sia questa funzione, se trovi "getInput" che ti serve. E dopo 10 anni la documentazione sarà errata, incompleta o mancante. getInputFromUserWhoInputsStringOrElseInformReaderOfError è certamente troppo lungo, ma capire cosa è lungo è meglio (e non mi interessa che le donne affermino che le dimensioni non contano).
Dainius,

Non sono d'accordo in questo caso. Penso che solo leggendo il codice sarebbe abbastanza facile capire cosa fa getInput (), specialmente se stampa "input non validi" o qualcosa subito dopo. Ci sono sicuramente momenti in cui un nome più lungo può essere migliore però - lo modificherò in!
BlackJack,

spesso dipende dal contesto, ma nella mia esperienza il nome più lungo è migliore (ma non finché getInputFromUserWhoInputsStringOrElseInformReaderOfError). E il contesto è molto importante in quanto file.read () è più veloce di file.readAllFileAsByteArray (). Ma come ho detto di solito il nome più lungo IMHO fornisce ulteriori informazioni.
Dainius,

1
Se la documentazione è errata, incompleta o mancante, la base di codice è comunque condannata.
Christopher Mahan,

2
Questo sta rispondendo a una domanda che non è stata posta.

16

No, non lo farà. In generale, quando viene compilato il codice, i nomi delle variabili vengono sostituiti dall'indirizzo di memoria a cui si riferiscono. I computer non sanno nulla dei nomi delle variabili; vogliono solo sapere dove sono memorizzati i valori.

Le variabili sono simboli, niente di più. Sostituiscono i valori esadecimali con i nomi in modo che i programmatori possano capire più facilmente cosa stanno facendo. Quindi, non ci sarà alcun aumento delle prestazioni scegliendo nomi di variabili più brevi.

Detto questo, potresti ottenere minuscoli (e sto parlando microscopici) miglioramenti nei tempi di compilazione e nella prima interpretazione di JIT, ma questo è solo perché il parser impiega alcuni cicli della CPU in meno per leggere il nome della variabile. Questo è un costo una tantum ed è statisticamente insignificante quando preoccuparsi delle prestazioni.


11
Sebbene la risposta sia corretta per la programmazione dell'applicazione, l'OP fa riferimento a siti Web e quindi esiste la possibilità che stia utilizzando un linguaggio interpretato. In tal caso, il codice dovrebbe essere letto dal file, quindi interpretato. In questo caso, un nome di variabile più lungo richiederà più tempo per caricare e analizzare. Tuttavia, il guadagno in termini di prestazioni sarà insignificante e fortemente compensato dalla seccatura aggiuntiva per il programmatore di leggere e comprendere il codice.
Gavin Coates,

1
@Gavin È corretto anche per le lingue interpretate - "JIT prima interpretazione". La maggior parte dei linguaggi interpretati ora vengono compilati mentre eseguono anziché l'esecuzione riga per riga, AFAIK.
Michael K,

1
Michael - per compilare, il file deve essere prima letto in memoria. Questo processo richiederà più tempo a seconda della lunghezza del file. Nomi variabili più lunghi = file più lunghi.
Gavin Coates,

La domanda è taggata come PHP. PHP non ha ancora JIT, che sarà una nuova funzionalità della versione 8.0 prevista per la fine di quest'anno. Si compila in codice byte prima dell'esecuzione e il bytecode viene generalmente memorizzato nella cache sui server Web per essere utilizzato in più richieste.
bdsl

8

A meno che non si stia utilizzando la cache del codice operativo (nota anche come "acceleratori PHP"), si ha effettivamente un impatto. Ma quell'impatto è così basso, che può essere trascurato. Se si utilizza la cache del codice operativo, non si verifica alcun impatto.


1
e se ti preoccupi così tanto delle prestazioni da considerare di accorciare i nomi delle variabili per guadagnare qualche ciclo, non usare la cache del codice operativo sarebbe criminale ... e si consiglia di passare a un linguaggio compilato come C.
SF.

Ma ovviamente quell'impatto è cumulativo, quindi maggiore è l'applicazione, maggiore è l'impatto, giusto?
n00dles,

Zend Opcache è stato spedito con PHP per diversi anni, quindi tutti dovrebbero usarlo. Penso che sia generalmente abilitato di default.
bdsl

3

Mentre Michael ha ragione per la programmazione dell'applicazione, la tua domanda si riferisce allo sviluppo web con PHP, che è un linguaggio interpretato. In tal caso, il codice dovrebbe essere letto dal file, quindi interpretato. In questo caso, un nome di variabile più lungo richiederà più tempo per caricare e analizzare.

Tuttavia, il risultato della performance sarà insignificante e probabilmente sarà nella regione di frazioni di un millisecondo per un intero script. Puoi sempre provarlo con uno script di esempio e utilizzare un metodo di temporizzazione come quello dettagliato su http://www.developerfusion.com/code/2058/determine-execution-time-in-php/ ma probabilmente non lo farà avviare il cronometraggio fino a dopo che il file è stato letto. Inoltre, il tempo di esecuzione tra i tentativi varierà molto più della differenza tra le lunghezze dei nomi delle variabili, quindi sarà necessario eseguire un numero significativo di tentativi e prendere la media di ciascuno prima di poter ottenere una media lontanamente significativa.

Come sottolinea BlackJack, i nomi più lunghi possono essere molto più difficili da comprendere e richiedono molto più sforzo per scrivere (e sono molto più inclini a errori di battitura). Sebbene ci possa essere un piccolo aumento delle prestazioni, ciò non giustifica la seccatura aggiuntiva creata per il programmatore. Pertanto, sono preferiti nomi di variabili brevi, concisi e di facile comprensione.

Quindi in breve, non preoccuparti del nome di lunghezza variabile, ma concentrati invece sulla scrittura di codice pulito e significativo.


1

Forse :

Il codice del server viene in genere compilato e la lunghezza del nome della variabile non lo influenzerà per i motivi indicati. Tuttavia, se il nome della variabile viene utilizzato per creare markup varie operazioni di stringa. Poiché la risposta HTTP (contenente markup / dati json restituiti / resi) è più grande, ci vorrà un po ' più di tempo, anche se la differenza sarà trascurabile. Se JavaScript non è minimizzato, sarà un file più grande, impiegando più tempo a viaggiare verso il client.

Oltre a minimizzare i file JavaScript, qualsiasi sforzo di ottimizzazione per un'applicazione Web / sito Web verrà speso meglio su altri aspetti.


1

Sì, ma non nel senso a cui stai pensando.

Con nomi di variabili errati, gli sviluppatori verranno facilmente confusi nel codice sorgente. Sarà difficile da leggere e difficile da capire.

Alla fine, il codice sorgente sarà difficile da mantenere e sarà quasi impossibile farlo evolvere. Ciò porterà inevitabilmente a maggiori costi di manutenzione, maggiori costi di sviluppo, più bug e prestazioni peggiori .

Il nome della variabile non avrà assolutamente alcuna influenza in fase di esecuzione e totalmente trascurabile al momento della compilazione. Ma i nomi cattivi porteranno inevitabilmente a cattive prestazioni perché nessuno capisce il codice e finisce in una pila di hack uno sopra l'altro, peggiorando le cose ogni volta.

Leggi questi per conoscere il buon nome della variabile: http://tottinge.blogsome.com/meaningfulnames

Nota che se senti la necessità di un nome di variabile molto lungo, significa che il tuo codice è scarsamente progettato. Un nome di variabile viene sempre espresso in un contesto: spazio dei nomi, nome della classe, nome del file, cartella, nome della funzione, ecc. Pertanto, se il nome deve essere lungo per essere esplicito, ciò significa che la cosa che si sta tentando di nominare NON FA ' T QUI APPENA QUI . In questo caso, pensa a mettere questo codice nel posto appropriato o crealo se non esiste ancora.


0

La risposta è ovviamente sì, per quanto riguarda php.

Le risposte che dicono che non farà la differenza non sono necessariamente corrette. Ad esempio, ho un piccolo script php, solo poche righe, ma deve essere ripetuto circa 1.950.000 volte prima di terminare il suo lavoro, quindi anche se una singola esecuzione dello script potrebbe non essere notata, quelle frazioni di secondo si sommano sostanzialmente quando loop più volte.


1
Ma ti sbagli. Qualsiasi interprete PHP decente analizzerà il codice una sola volta. I ragazzi che scrivono interpreti php non sono stupidi.
gnasher729,

@ gnasher729 Stai facendo ipotesi su come funziona l'interprete o l'intero server e non dovresti mai farlo. Anche se analizzerà una sola volta per ogni esecuzione, potrebbe ripetere l'analisi a ogni esecuzione e non memorizzare nella cache una rappresentazione analizzata (altri sistemi lo faranno ma non è possibile conoscerlo in anticipo). E generalmente più byte è uno script, più tempo ci vorrà per analizzare. Quindi Diorthotis non ha torto in generale, potrebbe avere torto solo riguardo a un sistema specifico.
Mecki

0

Puoi usare nomi brevi che rendono il tuo codice meno leggibile. Risparmierai un microsecondo o due. Ma poiché il codice è meno leggibile, è più difficile migliorarlo e renderlo più veloce. Quindi il tuo codice non mantenibile, non migliorabile con nomi brevi finirà per essere significativamente più lento alla fine.

Quindi, per rispondere alla tua domanda ("influisce sulle prestazioni"): Sì, ma non nel modo che preferisci.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.