"Presesja" składała się z kilku części. Na początku, prelegent pokazał, w jaki sposób "wpleść" elementy związane z wydajnością w cały cykl prowadzenia projektu i jak uczulić zespół na zagadnienia związane z prędkością działania systemu.
Potem pokazane były pewne elementy związane z konkretnymi elementami CLR (motoru .NET). W jaki sposób można optymalizować aplikację pod kątem prędkości działania a także - jak optymalizować zużycie pamięci (dużo uwag o działaniu GC i dzieleniu pamięci). Pod koniec dnia prelegenci skupili się nad aplikacjami ASP.NET i omówili dosyć szczegółowo zarówno sposób działania serwera WWW, jak mierzyć tego typu aplikacje i jak je poprawić by działały szybciej.
Poniżej kilka luźnych (jeszcze nieuporządkowanych) uwag związanych z analizą wydajności :

Jeżeli wydajność aplikacji nie jest mierzona, to nie bardzo wiadomo czy system działa szybciej/wolniej. A, jak wspominał prowadzący inżynierowie powinni mierzyć (pomiarów nie wykonują artyści). Zdefiniowanie "bazowej" wydajności pozwoli na dalsze prace.

Jeżeli budowany jest system na "zlecenie" klienta, to warto cały czas mieć przed oczami jego rzeczywiste wymagania. Jakie elementy naprawdę muszą działać szybko, które są mniej krytyczne i dlaczego.

Nie warto także zabierać się do "optymalizacji" bez określenia budżetu jaki na to można przeznaczyć - co ściśle wiąże się z wymaganiami klienta. Skupiamy się tak naprawdę na "big4" - czyli na optymalizacji zużycia pamięci, procesora, dysku i sieci. Jeżeli optymalizujemy, to musimy brać pod uwagę istniejące ograniczenia zasobów. Ale czasami - jednym ze sposobów optymalizacji może być po prostu zwiększenie zasobów (choć - w niektórych sytuacjach się technicznie nie da tego zrobić).

Jeżeli analizujemy wydajność modelujemy dane tak by one przypominały te, z jakimi mamy do czynienia w realnym środowisku działania aplikacji (inna jest charakterystyka wydajnościowa tablicy gdy elementów jest 1000 a inna - gdy 10 mln).

System przede wszystkim powinien być użyteczny. Nadmierna "rozszerzalność", budowa uniwersalnych frameworków tam gdzie nie jest to wymagane powoduje, że system działa wolno. Podobnie ma się rzecz w przypadku zbyt "obiektowej" struktury aplikacji. Wtedy, w wielu miejscach dane są powielane, konwertowane, różnego rodzaju "konstruktory kopiujące" wiele razy obrabiają niepotrzebnie ten sam zestaw informacji. Warto zachować umiar i zdrowy rozsądek.

Platforma .NET budowana jest przy pewnych założeniach. Na przykład, że większość obiektów żyje krótko (tak zakłada Garbage Collector - automatyczny odśmiecacz). Jeżeli twórca aplikacji przyjmie inne założenia - to jego system będzie działał wolno....

Kod jittowany nie jest dzielony. Jest to kod dynamiczny. Czyli - jeżeli chce się mieć współdzielony kod, to należy użyć NGEN i/lub GAC (ale to ma także inne konsekwencje). Tu mają się zmienić pewne elementy w .NET 4.0.
Natomiast z natury kod niezarządzany (zwykłe DLL-ki) istnieją w jednej kopii równocześnie. Dotyczy to także .NET. Czyli w pamięci np. jest tylko jedna kopia bibliotek .NET Framework.
/CDN/