Come da titolo, scusate l'ignoranza.
Come da titolo, scusate l'ignoranza.
Se parliamo del codice generato la risposta è no, l'occupazione di memoria di "i=1" è identico a "indice=1"
Altra cosa è per il codice sorgente, ovviamente![]()
01010011 01100001 01101101 01110101 01100101 01101100 01100101 01011111 00110111 00110000
All errors are undocumented features waiting to be discovered.
Si, in fase di compilazione nomi lunghi richiederanno più tempo, ma non così tanto da giustificare lo sforzo necessario per ricordarsi cosè la variabile 'a', cosa è la variabile 'b', cosa la variabile 'c' ...
Esistono comunque dei limiti alla lunghezza dei nomi delle varibili, benché si possano usare nomi di variabili veramente molto lunghi, ogni nome è valutato fino ad un certo numero di caratteri, la parte oltre questo limite di solito è semplicemente ignorata![]()
01010011 01100001 01101101 01110101 01100101 01101100 01100101 01011111 00110111 00110000
All errors are undocumented features waiting to be discovered.
grazie della risposta, il punto è che sto sviluppando una applicazione php veramente immensa e ho intenzione di encodarla io tramite un mio parser (quindi aggiungerò di rinominare le variabili automaticamente, non certo facendolo a mano) prima di farla lavorare da un altro encoder che salvi il bytecode così da non farlo ricompilare nuovamente.
Dato che PHP è dinamico variabili con nomi lunghi occuperanno effettivamente più memoria a runtime, ma rispetto alle prestazioni generali di PHP dubito seriamente che la cosa abbia un impatto misurabile (sia sul parsing che sul runtime).
Amaro C++, il gusto pieno dell'undefined behavior.
@MItaly PHP non ha limiti sulla lunghezza del nome delle variabili, puoi nominare una variabile con 4G di caratteri volendo, poi vediamo se non ha impatto e.e
"Quid enim est, quod contra vim sine vi fieri possit?" - Cicerone, Ad Familiares
Si intendeva "entro limiti ragionevoli"![]()
Amaro C++, il gusto pieno dell'undefined behavior.