Da jeg for mange år siden var en lille dreng der gik ude på DTU og lærte hvordan man blev ingeniør, var en af de ting jeg synes var rigtigt sjovt at hukommelsesoptimere. Præcis hvorfor ved jeg ikke, men det tiltalte mig på en eller anden måde rigtigt meget at få vredet lige otte bytes mere ud af et eller andet minimalt embedded system, eller at få en datastruktur til at fylde lige to bytes mindre pr. entry.
Det er mig en gåde hvorfor jeg dengang syntes at det var skægt, og efterhånden som jeg blev ældre lagde min fascination af den her helt særlige form for totur sig, og blev afløst af en langt mere naturlig foragt for den slags programmering. Ikke at jeg synes man skal svine unødigt med hukommelse, men inden for moderne udvikling så kan det simpelthen ikke være rigtigt at programmøren selv skal side og manuelt tilrette hver eneste datastruktur, og selv sidde og finde hver eneste lille ekstra byte ud af hukommelsen – og det ER selv følgelig heller ikke rigtigt. Med garbage collection, smartere compilere og nærmest uendelig performance og hukommelse så er det ikke noget programmører i dag nogensinde prøver at beskæftige sig med.
Derfor har det også overrasket mig pænt meget, når jeg tænker tilbage på hvad jeg har lavet den sidste uge. Jeg har siddet og kigget på lange, lange stackdumps, aflæst hvor meget hukkomelse hver enkelt object bruger, flyttet rundt på kode, tænkt datastrukturer om og klappet i mine små hænder hver gang jeg har sparet 15-20 bytes. Præcis som da jeg var en lille dreng på DTU – forskellen er bare at i dag hader jeg det som pesten.
Det jeg laver er at gå alle vores ASP.NET controls igennem og få styr på hvor meget de plads de bruger når de er serialiseret ud i ASP.NETs ViewState. 200 controls, hvoraf hveranden gemmer bare 100 bytes i viewstate giver 10kb i ViewState, og det bliver overført frem og tilbage mellem server og klient hvert eneste gang siden forsager et postback – og med moderne ting som AJAX og asynkrone postbacks, så kan det ske masser af gange i minuttet. I Skum 3 har vi nogen widgets (Skum fiduser) og hver gang de bliver flyttet melder de tilbage til serveren, at de bor et andet sted igennem et postback: Med et ViewState på 10kb skal man kun flytte en widget 50 gange, før man har overført en megabyte data. Ingen billeder, ingen ting, bare retursvar til serveren om hvor den her widget bor nu.
Med andre ord, hvis man ikke passer ekstremt meget på hvad man har i ViewState laver man meget, meget nemt den største og tungeste website nogensinde – uden at man får noget ekstra funktionalitet ud af det.
Så nu går jeg altså alle vore controls igennem en for en og sikrer mig at de ikke sviner i ViewState, ligesom programmørene i 1978 gik deres C eller Fortran kode igennem funktion for funtion, og datastruktur for datastruktur for at sikre sig de ikke svinede med hukommelsen. Jeg har lært mig følgende regler som alle folk burde følge når de udvikler ASP.NET controls:
- Det eneste der skal bo i ViewState er information som er direkte forsaget af en brugers handlinger, og ikke er gemt i databasen endnu.
- Alt, hvis værdi på nogensomhelst måde kan sættes før eller under en controls init-event skal sættes der. Efter Init event’et tracker ViewState og så bliver alting serialiseret ud til klienten.
- I UserControls skal alle værdier der overhovedet kan sættes i .ascx filen (som properties på et tag) sættes der. Den slags properties bliver sat før ViewState begynder og tracke, og derfor sviner de ikke i ViewState.
- Hvis man endelig ikke kan undgå at noget skal være i ViewState, så vær ekstremt omhyggelig med hvad du kommer derind. Alt andet end strings, bytes, bools og andre simple typer bliver serialiseret med en byteserializer der er ekstremt ueffektiv. Controls i ViewState er især super forbudt – brug ID’er i stedet. Overload hellere SaveViewstate og LoadViewstate en gang for meget end en gang for lidt.
ViewState kan være svært at forstå, og det er svært at læse sig frem til hvad det er og hvad det gør, hvis man kun bruger Microsofts dokumentation. Den her artikel er absolut den bedste jeg har set om ViewState og det bør være “required reading” for alle der har med ASP.NET at gøre: