Sto finalizzando uno dei miei progetti e dando un'occhiata all'intero progetto alla ricerca di errori, errori e errori nelle prestazioni. Sto usando MVC. Ne ho preso uno Do not e cioè:Cosa sono alcune prestazioni [Dos/Don'ts] in C# -ASP.NET
Non inserire mai una RenderPartial in un ciclo. rallenterà drasticamente l'intero server.
Mai memorizzare un WebControl in sessione.
Poiché ha un riferimento all'oggetto Page, esso finisce per memorizzare il controllo ogni alla sessione.
Inoltre, è un componente che appartiene alla pagina, quindi se lo memorizzi nello stato Sessione e poi provi a usarlo in un'altra pagina, non funzionerà correttamente. (Sono stato lì, fatto così ...) :) – Guffa
Vorrei aggiungere, se possibile, evitare lo stato di sessione o altro stato globale. Non tanto per le prestazioni, ma per la manutenibilità generale. – JohannesH
Avete eseguito il programma tramite FxCop? Ha un insieme di regole per le prestazioni.
Non ottimizzare in modo prematuro. :) Se il sito non è performante, profila il codice per determinare dove trascorrere il tuo tempo.
Non profilo o altrimenti giudicare le prestazioni nella configurazione di debug. La configurazione di debug non è pensata per essere veloce, e si possono trarre conclusioni sulle prestazioni che sono sbagliate (come l'idea che le viste parziali/i controlli utente siano lenti, questo è vero nella configurazione di debug ma non nella configurazione di rilascio). Quando si definisce il profilo per misurare le prestazioni, è necessario utilizzare la configurazione di rilascio in modo da poter vedere dove si trovano i problemi reali.
Molto, MOLTO vero. Inoltre, non dimenticare di pubblicare in modalità di rilascio ;-) –
Utilizzare solo i blocchi try/catch quando necessario. Fanno rallentare la tua applicazione.
MODIFICA per la chiarezza: Per "necessario" intendo, per la cattura di errori reali.
Se è possibile scrivere del codice ed essere proattivi per garantire che l'errore non venga generato, è più performante che lasciare generare un'eccezione, quindi gestirla.
Non utilizzare eccezioni per controllare il flusso del programma. Non so chi l'abbia detto prima, ma ricordo la frase "Le eccezioni dovrebbero essere eccezionali!". Dovrebbero essere nei casi in cui si verifichino problemi imprevisti, cose che non possono essere testate prima dell'esecuzione del codice e del lancio.
il peggior esempio che vedo tutti a spesso è qualcosa in questo senso ...
int i = 0;
try
{
i = int.Parse(txt);
} catch {Exception x) {
// Do nothing, i = 0
}
Questa è ovviamente una versione specifica della regola più generale "solo il codice di scrittura è necessario, il codice non necessario rallenta l'applicazione". Capire quali linee siano "inutili" è la parte difficile. –
C'è solo un costo quando viene lanciata un'eccezione. Un blocco catch try non avrà alcun impatto sulle prestazioni del tuo codice. – Charlie
Suppongo che questo dovrebbe essere più "solleva eccezioni solo per la gestione degli errori, mai per il flusso di applicazioni valido e comune perché lanciare un'eccezione è davvero costoso". – Alex
In C#, gli oggetti vengono sempre creati con il nuovo. Questo da solo può essere un inconveniente in una certa prospettiva. Ad esempio, se si crea un oggetto all'interno di un ciclo (ovvero viene creato un nuovo oggetto per ogni iterazione nel ciclo), è possibile rallentare il programma.
for (int i = 0; i < 1000; ++i)
{
Object o = new Object();
//...
}
Creare invece un'istanza al di fuori del ciclo. Oggetto o = nuovo oggetto();
Object o = new Object();
for (int i = 0; i < 1000; ++i)
{
//...
}
creare solo un oggetto in un ciclo se si hanno veramente a ...
Forse facendo un po 'di C++ potrebbe aiutare a capire i meccanismi dietro e sapere quando e dove per ottimizzare il codice. Anche se C++ è una lingua diversa, ci sono molte cose che puoi applicare ad altre lingue una volta compreso l'essenziale della gestione della memoria (nuovi, cancella, puntatori, array dinamici/array statici, ecc.).
Questo è esattamente il tipo di ottimizzazione delle prestazioni che si dovrebbe evitare a meno che non si riveli un problema . Molto spesso, il codice è reso molto più complesso senza alcun miglioramento delle prestazioni. La gestione della memoria in C++ è una storia completamente diversa ... – Alex
Detto questo, creare oggetti è davvero economico. Ayende ha profilato questo: http://ayende.com/Blog/archive/2008/02/27/Creating-objects--Perf-implications.aspx –
@Erik: Se la sua classe effettuasse effettivamente operazioni serie, non sarebbe così economico;) @Alex: per ogni nuovo ci deve essere una cancellazione da qualche parte ... in C# il garbage collector fa l'eliminazione per te. Detto questo se crei e distruggi costantemente oggetti che stanno allocando molta memoria o che hanno bisogno di fare certi lavori ... beh finirai per avere un casino! Se capisci il C++ lo capiresti. – Partial
La maggior parte dei problemi di prestazioni è dovuta all'accesso al disco o alle chiamate attraverso le reti.
Quindi fai attenzione a come e quanto spesso accedi al file system o al database. Hai bisogno di fare così tante chiamate attraverso la rete, o potresti farlo in una singola chiamata.
Un buon esempio:
In questo caso una soluzione migliore può essere scrivere codice personalizzato per memorizzare e leggere il valore.
NON giocherellare con la garbage collection esplicita.
Caching aiuterebbe a migliorare le prestazioni, ma si dovrebbe essere attento uso solo in cui ha senso
USARE metodi statici - ma solo se il metodo viene utilizzato di frequente.
non segnare una variabile come statica a meno che non davvero desidera il valore della variabile di essere la stessa in tutte le istanze (un altro sviluppatore ha fatto questo e mi sono divertito il debug perché abbiamo ottenuto un comportamento strano solo quando più utenti hanno colpito il sito). Questo non è per motivi di prestazioni, ma solo un buon consiglio.
La cosa su RenderPartial è * significativamente * più vera in modalità di debug rispetto alla modalità di rilascio. In modalità debug il sovraccarico è schiacciante, poiché sonda l'ascx ad ogni iterazione. Nella modalità di rilascio questo è memorizzato nella cache, quindi in genere non è affatto male. –