Soci blog

Amikor profilerrel megnézünk egy .NET kódot sokszor megdöbbentő helyen lesz benne bottleneck.

Az alábbi kód 1% időt visz el egy nagyon processzorintenzív kódban:

if (bar.L == 0)

Ami ebben lassú, az a System.Decimal.op_Implicit(int32). A bar.L egy decimal. Érdekes, mi?
Mi a megoldás? A 0 legyen valóban decimal, de int, amit konvertálni kell:

if (bar.L == 0M)

1% kevés, de sok 1% már számít.

A unit tesztek kiváló sebességmérési célok lehetnek, mivel kimagozottan futtatnak egy adott kódrészletet. A unit teszten jobb gomb, create performace session. Zseniális, csak nem megy, ha 64 bitesre van állítva a unit teszt host. Nem láttam ledokumentálva (vagy csak nálam nem megy ez).
Egyszerűen soha nem ér véget a tesztelés, beragad a profiler session.

A VS coverage-e ezt mutatja, hogy ez a sor csak részben van lefedve:

return (GetSourceItem(step) - this[step - 1]) * e + this[step - 1];

Nincs benne && vagy ||, akkor triviális lenne. Én már tudom a választ. :)

Update: alul, kommentben ott a megoldás.

Az RC óta elfelejtettem, hát leírom magamnak.

Egyszerű, ha tudod hol kell keresni.

És végre gyorsan jön, de lehet, hogy csak azért, mert alszanak még Amerikában.

Itt.
Remélem ez már segít, mert már kezd az agyamra menni a a napi 10 crash.

Ez igencsak bosszantó volt, remélem a fix megoldja.
Nekem nem tablet pcm van, mégis előjön.
https://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=26662

Az NDoc halott, van helyette SandCastle. Nagyon jó, imádom. Ezzel csinálják a VS doksiját is. Van még kétely valakiben?
Az is jó, hogy nem kell kézzel írnom a konfigját, mert van hozzá Sandcastle Help File Builder, ami hasonló GUI, mint az ndochoz volt.
Aztán, hogy ne kelljen sokat gépelni az xml kommenteket, ott a GhostDoc. Beépül a VS-be, és CTRL-ALT-D-vel létrehoz egy komment vázat az adott kódrészhez. Meglepően ügyesen, ha angol neveket használunk a kódban.
Mindhárom eszköz zseniális és INGYENES. Aki ezek után nem dokumentálja a kódját, annak 1-es. :)

Felraktam a gépemre a Hyper-V-t. A VSTS profilert akartam használni, de azt mondta, No data collected.
Szerencsére megtaláltam ezt:
VS2008 does not support profiling in virtual environments (VMWare, VPC, Hyper-V).

Ez a jelek szerint nem csak virtuális guest-ekre vonatkozik, hanem a hostra is. Kikapcsoltam a BIOS-ban a virtualizálás támogatást, és egyből elindult a profiler.

Ezentúl rebootkor el kell döntenem, guest-eket akarok futtatni, vagy profiler-ezni.

A Visual Studio számomra egyik egyik legkedvesebb eszköze a Profiler. Számos cégnek oldottam már meg vele teljesítményproblémákat, amelyeket profiler nélkül sokkal nehezebb lett volna.
A profiler arra képes, hogy egy futó program belső részeinek futási idejét képes mérni. Működhet sampling módban, ilyenkor bizonyos időközönként (alapban 10 millió órajelciklusonként) belenéz a futó programba, és megnézi a verem állapotát, azaz, hogy éppen melyik metódusban van a vezérlés.
A másik mód az instrumentation, ekkor kódot injektálnak az futtatandó assembly-kbe, így belülről tudják mérni, mi-mennyi ideig futott.
A sampling nem sokat lassít a mérendő programon, de pontatlanabb, az intrumentation pontos, de nagyon sokat lassít a célprogramon.
Én első körben a sampling-et használom, ha csak ki akarom szúrni a kód leglassabb részét. Az intrumentation megmutatja azt is, hányszor hívtak meg egy metódust, azaz nem kell elvetni, csak másra való, mint a sampling.
A teljesítményhangolásban az a szép, hogy intuitíven sokszor nagyon mást optimalizálna az ember, mint a mérések alapján.

Az ábrán az látszik, hogy az idő jelentős részét a DateTime.Hour hívás viszi el. Kicsit gyanús ez, de sűrűbb mintavétellel vagy instrumentation segítségével jobban rá lehet nézni a körmére. Ha igaza van (valószínű), akkor ez pont olyan pont, amire álmomban nem gondoltam volna.

Érdemes megfigyelni még, hogy a felső toolbaron van egy láng ikon, arra kattintva a hívási fában azonnal levisznek a leglassabb metódushoz. Egyszerű, de szenzációs. Ez a 2008-ban jelent meg.

Kaptam egy igen nehezen megközelíthető problémát, amelyben a fókusz a TAB-ra átlépett egyes controlokat. Nem egy triviális TabStop=false probléma volt.
VS 2005-ös projektekről van szó, átkonvertáltam őket 2008-ra, hogy tudjam a fw. forráskódját is debugolni. Az _NT_SYMBOL_PATH= nekem be van állítva a gépen a publikus os szimbólumokra (elsősorban ahhoz amikor WinDbgozok), emiatt nem tudtam a vsből .net fw.-öt debugolni, mert előbb lehúzza a stripped szimbólumokat, a teljeshez már hozzá se nyúl. Ezért egy bat-ból indítom a vs-t, előtte kiütve az eredeti _NT_SYMBOL_PATH-t.
Így már ment a fw. forrás debug, de mivel a clr az ngenelt optimalizált kódot töltötte be, ezért nagyon sok típus belseje nem látszik normálisan. Erre megoldás itt található. Le lehet tiltani, hogy a CLR az ngenelt kódot töltse be, így már rendesen lehet debugolni.
Lehetne, ha nem lenne elcsúszva némelyik forráskód a pdb-ben található sorszámoktól. Ilyenkor van az, hogy teljesen más sorokon lépkedünk végig, mint amit a source ablakban látunk, pl. kommenteken lépked végig a debugger.
A megoldás erre egyszerűbb volt, mint gondoltam volna: próbaképpen kitöröltem 3 sort pl. a Control.cs elejéből, így visszaállt a szinkron.
Maga az alapprobléma egyébként abból adódott, hogy egy kompozit Third Party Contol explicit letiltotta
a TAB-olást, a ControlStyle-ból kivéve a Selectable flaget.

Az itt látható példa azokat a C# kódfájlokat listázza ki, amelyek árván maradtak, azaz ott vannak a fájlrendszerben, de nincsenek benne egy csproj fájlban.
Az egész számomra azért érdekes, mert szerintem igen tömören és elegánsan parsolják az xml csproj fájlt Powershellel.
A lopás árnyékát el nem kerülve, de idemásolom a példát a fenti forrástól:

param([string]$csproj = $(throw 'csproj file is required'))

$csproj = Resolve-Path $csproj
$dir = Split-Path $csproj

# get the files that are included in compilation
$xml = [xml](Get-Content $csproj)
$files_from_csproj = $xml.project.itemgroup |
	%{ $_.Compile } |
	%{ $_.Include } |
	?{ $_ } |
	%{ Join-Path $dir $_ } |
	Sort-Object

# get the files from the dir
$files_from_dir = Get-ChildItem $dir -Recurse -Filter *.cs |
	%{ $_.FullName } |
	Sort-Object

Compare-Object $files_from_csproj $files_from_dir

Tegnap megjelent a VS 2008 SP1, korábban hiányoltam.
Előtte le kellett futtatni a VS beta dirib-darabokat leszedő eszközt, a Visual Studio 2008 Service Pack Preparation Tool-t.
A takarító cucc elszállt, annak rendje és módja szerint, a Team Foundation Explorer matatása közben. Megpróbáltam repair-elni azt az eredeti DVD-ről, ugyanazzal a hibával elszállt. A logban láttam, hogy valamit akar a G: drive-ról, annak idején erről telepítettem, de most nem arról akartam repair-elni. Berakom a G:-be a DVD-t, és a repair sikeres. Most emlegetem a telepítő-írót kicsit. :)
A removal tool ezek után már simán működik persze, mehet az SP telepítő. A mostanában szokásos webes telepítőről van szó, ami pici, de aztán lehúzza magára az univerzumot. Érdekes, hogy egyszerre elindítottam egy X64-es és egy X86-os gépen is, és az X64-en vagy 3x annyi letöltési időt ír ki, hiába, hosszabb adat- és címbusz, hosszabb kód.
A telepítés nem kapkodja el, jó 1.5 órát elmolyolt, de felment. Kíváncsi vagyok a korábbi heap probléma előjön-e ezzel a végleges fw-kel.

Rosario-nak hívják a drágámat, áprilisi CTP-nél járunk.
No kérem, ahogy nézem ebből a postból, az architect (kevésbé nagyképűen tervező) cuccok igen ütősek lesznek benne. Ha mást nem, hát a képeket érdemes megnézni, sokat mesélnek, mi várható.