Archive for the ‘VS 2008’ Category

Érdekes .NET perf tapasztalat

Saturday, March 5th, 2011

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.

Disable/turn off “Attach Security Warning” in Visual Studio

Monday, May 10th, 2010

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

Sandcastle és társai

Wednesday, September 30th, 2009

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. :)

VS Profiler nem megy Hyper-V-s gépen

Monday, April 27th, 2009

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.

Visual Studio Team System teljesítményanalízis

Wednesday, January 21st, 2009

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.

Debugolás a .NET fw. forrása segítségével

Thursday, December 11th, 2008

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.

VS 2008 SP1 telepítési tapasztalatok

Tuesday, August 12th, 2008

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.

Visual Studio 2008 Support for SQL Server 2008

Wednesday, February 20th, 2008

A VS 2005 és 2008 nem tud kapcsolódni az SQL Server 2008 CTPhez, csak ezen patch után.