Più grande è uno script o una classe, maggiore è la memoria utilizzata per ogni istanza. PHP non ha un modo per condividere lo spazio di memoria di librerie e classi, quindi creare enormi script per un sito Web non è una grande idea.
L'approccio tipico dovrebbe essere quello di suddividere le classi in blocchi in modo tale che è necessario includere solo per script ciò che è effettivamente necessario per eseguire quello script.
Inoltre, è improbabile che causi problemi di prestazioni a meno che tu non abbia un'enorme quantità di traffico - e quindi potresti probabilmente risolvere i tuoi problemi più facilmente delle classi di refactoring.
Quando uno script viene caricato, richiede una quantità di memoria fissa per analizzarlo. Più è grande, più memoria richiede. Successivamente, lo script stesso viene eseguito, eseguendo qualsiasi codice di livello superiore (non in una classe o una funzione globale). Se questo include qualsiasi istruzione require/include, questi script vengono caricati (se necessario). Se crea oggetti, questo richiede più memoria.
Tuttavia, la dimensione di ogni istanza della classe è influenzata solo dai dati memorizzati. A parte questa correzione, il consiglio qui è azzeccato: dividi le tue classi in base alle responsabilità. La ragione di questo ha anche a che fare con la facilità di sviluppo rispetto alle prestazioni. Supponi di avere una classe mostro piena di metodi statici. Se l'applicazione utilizza la maggior parte di questi metodi per ogni richiesta, la suddivisione non avrà alcun vantaggio in termini di prestazioni poiché entrambi gli script finiranno per essere caricati comunque. Ma se puoi raggruppare i metodi in sottosistemi logici, saranno più facili da capire e da lavorare.
Ovviamente questo dipende dal caso d'uso. Se li rompi, e finisci usando solo dire l'1% di esso e carichi solo questo 1% di esso, ovviamente sarà meno dispendioso in termini di risorse rispetto al caricamento del 100% e quindi usando l'1%. – houbysoft
Stai chiedendo due cose diverse qui. L '"impatto sulle prestazioni" è zero. Mentre "ad alta intensità di risorse", sì lo è, in termini di memoria. Se si rompe il codice in parti più piccole, si avrà un minore utilizzo di memoria, ma alla fine più I/O. Usa xdebug invece di consigli generalizzati. – mario
Le prestazioni non dovrebbero essere la vostra preoccupazione qui ... i vantaggi che otterrete in termini di manutenibilità e la possibilità di leggere il codice supereranno di gran lunga qualsiasi (probabilmente minore) impatto sulle prestazioni che potrebbe verificarsi. – Thanatos