Ricorda che il codice BCL di .NET Framework è ottimizzato per utile per il maggior numero di programmatori , non per le buone prestazioni nella tua particolare applicazione. Quindi è molto probabile che tu possa battere le prestazioni di un particolare pezzo di esso, anche se non sei un Rico Mariani .
Tuttavia, dovresti imparare da quegli esperti, in particolare i mantra come "Misura, Misura, Misura". Ciò non significa che devi compilare ed eseguire il debug della tua versione completamente prima di capire se puoi battere il BCL. Significa che identifica quali parti del codice della libreria ti causano problemi di prestazioni, quindi non sprecare sforzi reinventando ciò che non importa.
Una volta che sai quanto è buono o cattivo il rendimento del codice per scopi generici, hai buone probabilità di prevedere se sarai in grado di batterlo. Soprattutto se esegui alcuni test di scalabilità. Ci sono molti widget forniti dal framework in cui semplici operazioni come l'aggiunta di più elementi listbox 1 hanno una complessità quadratica (o peggiore) ... semplicemente perché il maggior numero di applicazioni non inserisce mai più di due dozzine di elementi nel controllo comunque. Dotato di una stima della complessità del runtime del widget standard (e della memoria) per le operazioni di cui hai bisogno, saprai esattamente dove hai la possibilità di fare meglio in un modo che paga dividendi per il tuo sforzo.
1 A volte la documentazione li mette in evidenza e fornisce anche un modo per inserire codice ottimizzato per l'applicazione senza buttare via l'intero componente della libreria. Ad esempio, ListView "modalità virtuale" o "Proprietario-Disegna" per i tradizionali controlli Win32.