Georg fährt extra nach Berlin um Steve Ballmer zu treffen

31 Tage Mango | Tag #24: Laufzeitanalyse

Die­ser Arti­kel ist Tag #24 der Serie 31 Tage Man­go von Jeff Blan­ken­burg.

Der Ori­gi­nal­ar­ti­kel befin­det sich hier: Day #24: Per­for­mance Ana­ly­sis.

Die­ser Arti­kel wur­de in der Ori­gi­nal­se­rie von Gast­au­tor Chris Koenig geschrie­ben. Bei Twit­ter kann Chris unter @chriskoenig erreicht wer­den.

Das Betriebs­ver­hal­ten ist eine wich­ti­ge Eigen­schaft jeder Anwen­dung, beson­ders aber bei Anwen­dun­gen, die auf res­sour­cen­be­schränk­ten, netz­ab­hän­gi­gen mobi­len Gerä­ten lau­fen. Als Anwen­der sieht man rela­tiv leicht, wenn eine Anwen­dung „lang­sam“ läuft — nicht so leicht ist es, fest­zu­stel­len, war­um die Anwen­dung sich so ver­hält. Ände­run­gen am Source Code zu machen, ohne dass man die Ursa­chen des schlech­ten Lauf­zeit­ver­hal­tens wirk­lich ver­stan­den hat, kann zu unnö­ti­gem Mehr­auf­wand füh­ren und das Pro­blem sogar ver­schlim­mern.

Also was machen? Seit der Ver­öf­fent­li­chung von Win­dows Pho­ne Man­go kön­nen wir den Grün­den für schlech­tes Lauf­zeit­ver­hal­ten leicht auf die Spur kom­men — bis run­ter zur ein­zel­nen Metho­de. Hier­für ver­wen­den wir das Werk­zeug Win­dows Pho­ne Pro­fi­ler. Sie kön­nen das neue Win­dows Pho­ne Pro­fi­ler Werk­zeug ver­wen­den, um Pro­ble­me im Lauf­zeit­ver­hal­ten zu iden­ti­fi­zie­ren. Der­ar­ti­ge Pro­ble­me kön­nen zum Bei­spiel Haupt­spei­cher­ver­brauch, Kom­ple­xi­tät des Visu­al Trees, Dau­er des Anwen­dungs­starts oder lang lau­fen­de Ope­ra­tio­nen sein.

Um die Leis­tungs­ana­ly­se zu star­ten, öff­nen Sie Ihr Win­dows Pho­ne Pro­jekt im Visu­al Stu­dio und wäh­len Sie „Start Win­dows Pho­ne Per­for­mance Ana­ly­sis“ aus dem Debug Menü oder drü­cken Sie Alt-F1:

Ach­tung: Ver­wech­seln Sie den Win­dows Pho­ne Pro­fi­ler nicht mit dem .NET Pro­fi­ler, wel­cher eben­falls im Debug Menü unter „Start per­for­mance ana­ly­sis (Alt-F2)“ zu fin­den ist.

Als ers­tes wer­den Sie gefragt, was für eine Art von Ana­ly­se Sie durch­füh­ren möch­ten. Wenn Sie sich nicht ganz sicher sind, dass es sich um ein Spei­cher­pro­blem han­delt, soll­ten Sie die Exe­cu­ti­on Ana­ly­sis star­ten:

Wenn Sie das Link „Launch App­li­ca­ti­on“ kli­cken, wird die Anwen­dung ent­we­der im Emu­la­tor oder auf dem ech­ten Gerät gestar­tet. Dabei wird auto­ma­tisch der Ana­ly­se­code hin­zu­ge­fügt. Sobald die Anwen­dung gestar­tet ist, füh­ren Sie die­je­ni­gen Funk­tio­nen der Anwen­dung aus, die am res­sour­cen­hung­rigs­ten sind oder die Ihre Anwen­der am häu­figs­ten ver­wen­den wer­den. Wäh­rend Sie die Anwen­dung benut­zen, wer­den vom Visu­al Stu­dio auto­ma­tisch Leis­tungs­da­ten ein­ge­sam­melt und auf­ge­zeich­net.

Sobald Sie Ihren Test­lauf abge­schlos­sen haben, wech­seln Sie zurück ins Visu­al Stu­dio und kli­cken auf das Link „Stop Pro­filing“:

Jetzt wird das Visu­al Stu­dio alle auf­ge­zeich­ne­ten Leis­tungs­da­ten in eine .SAP Datei spei­chern und die­se zu Ihrem Pro­jekt hin­zu­fü­gen. Der Datei­na­me beinhal­tet den Namen des Pro­jekts und den Zeit­punkt des Tests (z.B. DatabaseForMango_2011_11_14_17_59_27.sap). Die­se Auf­zeich­nung kann sofort oder spä­ter betrach­tet wer­den. In der Haupt­an­sicht der Ergeb­nis­se sehen Sie die ver­schie­de­nen Dia­gram­me, die zur Ver­fü­gung ste­hen. Die Dia­gram­me reprä­sen­tie­ren eine Rei­he ver­schie­de­ner Mes­sun­gen, die über­ein­an­der ange­zeigt wer­den um einen zeit­li­chen Ver­lauf der Leis­tung Ihrer Anwen­dung dar­zu­stel­len.

Von oben nach unten zei­gen die Dia­gram­me:

  • Bild­fre­quenz — Dies zeigt die auf­ge­zeich­ne­te Bild­fre­quenz. Nied­ri­ge Wer­te hier sind mög­li­che Pro­blem­stel­len und soll­ten etwas näher unter­sucht wer­den.
  • CPU Aus­las­tung % — Zeigt die CPU Aus­las­tung für ver­schie­de­ne Berei­che der Anwen­dung
    • Grü­ne Bal­ken reprä­sen­tie­ren den UI Thread — die­ser ver­dient beson­de­re Auf­merk­sam­keit, da eine hohe Aus­las­tung des UI Threads die Benut­zer­ober­flä­che ins Sto­cken bringt. Jeder Wert über 50% ist ein poten­zi­el­ler Pro­blem­be­reich.
    • Blaue Bal­ken reprä­sen­tie­ren Anwen­dungs­threads — das schließt selbst erstell­te Back­ground-Threads und den Com­po­si­ti­on Thread ein. Je mehr hier und nicht auf dem UI Thread statt­fin­det, umso bes­ser.
    • Graue Bal­ken reprä­sen­tie­ren Sys­tem­threads — dies sind Threads, die NICHT Teil Ihrer Anwen­dung sind. Sie reprä­sen­tie­ren Din­ge wie Back­ground Tasks, usw.
    • Wei­ße Bal­ken reprä­sen­tie­ren Threads im Leer­lauf — z.B. der „Sys­tem Idle Pro­cess“, den man auch aus dem Win­dows Task Mana­ger kennt. Da die­ser Wert mit der frei­en CPU Kapa­zi­tät kor­re­spon­diert, bedeu­ten höhe­re Wer­te hier eine flüs­si­ge­re Benut­zer­ober­flä­che.
  • Spei­cher­ver­brauch in MB — Wenn Sie hier zu irgend­ei­nem Zeit­punkt mehr als 90 MB ver­brau­chen, füh­ren Sie den ande­ren Test aus — 90 MB sind das Maxi­mum für eine erfolg­rei­che Zer­ti­fi­zie­rung im Mar­ket­place.
  • Sto­ry­boards — Ein „S“ wird immer dann ange­zeigt, wenn ein Sto­ry­board gestar­tet wur­de.
    • Rot reprä­sen­tiert auf der CPU aus­ge­führ­te Sto­ry­boards (da sie auf der CPU aus­ge­führt wer­den, haben die­se direkt einen schlech­ten Ein­fluss auf die Leis­tungs­fä­hig­keit der Benut­zer­schnitt­stel­le)
    • Lila reprä­sen­tiert auf der GPU aus­ge­führ­te Sto­ry­boards (die­se sind gut, da sie auf dem Com­po­si­tor Thread aus­ge­führt wer­den und kei­nen direk­ten Ein­fluss auf das Ver­hal­ten der Benut­zer­schnitt­stel­le haben).
  • Laden von Bil­dern — Ein „I“ wird immer dann ange­zeigt, wenn ein Bild in den Spei­cher gela­den wur­de.
  • Gar­ba­ge Collec­tion Events — Ein „G“ wird immer dann ange­zeigt, wenn der Gar­ba­ge Collec­tor gelau­fen ist.

Um Details zu den Daten hin­ter den Dia­gram­men zu sehen, benut­zen Sie die Maus und wäh­len Sie den Bereich, den Sie näher unter­su­chen möch­ten. Im unte­ren Bereich, der „Detail­ed Per­for­mance Ana­ly­sis“, wer­den War­nun­gen und infor­ma­ti­ve Nach­rich­ten ange­zeigt, die auf mög­li­che Pro­ble­me im aus­ge­wähl­ten Bereich hin­wei­sen:

In dem Bild oben sehen sie zwei War­nun­gen im Zusam­men­hang mit der Bild­fre­quenz. Die ers­te War­nung im Bild oben ent­hält bei­spiels­wei­se die fol­gen­de Infor­ma­ti­on:

Warning: Very low frame rate poten­ti­al­ly cau­sed by a high lay­out cost.

Total lay­out time (0.35 seconds) is high. Ele­ment System.Windows.Controls.ScrollViewer : Scroll­View­er took the most time in lay­out and is con­tri­bu­ting to the low frame rate. This could be becau­se CPU-bound ani­ma­ti­ons are causing lay­out updates. Go to the Per­for­mance Warnings menu in the navi­ga­ti­on tool­bar and select the Frames view. Sort the frames by cli­cking the CPU Time column hea­der and select the frames with the hig­hest CPU time. From the Frames view, select the Visu­al Tree opti­on and iden­ti­fy visu­al System.Windows.Controls.ScrollViewer : Scroll­View­er in the tree.

Die­se War­nung bezieht sich auf eine nied­ri­ge Bild­wie­der­hol­fre­quenz im Zusam­men­hang mit dem Auf­bau des Lay­outs im Scroll­View­er. Die vor­ge­schla­ge­ne Akti­on ist die Wahl der Frames Ansicht im Per­for­mance Warnings Menü. Wenn Sie den Bereich Detail­ed Per­for­mance genau­er anse­hen, sehen Sie direkt neben dem Ein­trag Per­for­mance Warnings einen But­ton für ein pop-up Menü, durch wel­ches Sie „tie­fer gra­ben“ kön­nen. Wenn Sie die Opti­on „Frames“ wäh­len, wer­den Sie etwa fol­gen­des sehen:

Die Lis­te der aus­ge­wähl­ten ein­zel­nen Frames offen­bart, dass ziem­lich vie­le davon eine CPU Aus­las­tung deut­lich über 50% haben — in unse­rem Fall sogar einer mit über 80%. Wenn wir die­sen Frame aus­wäh­len und dann zurück zum Navi­ga­ti­ons­me­nü neben dem Ein­trag Frames von gera­de eben, sehen wir, dass wir für die­sen Frame noch mehr Details anse­hen kön­nen. Wäh­len Sie die ein­zel­nen Ein­trä­ge aus dem Menü, um mehr Details zu den Vor­gän­gen in die­sem Frame zu bekom­men. Wenn Sie bei­spiels­wei­se die Opti­on Func­tions wäh­len, bekom­men Sie die auf­ge­ru­fe­nen Metho­den Ihrer Anwen­dung ange­zeigt (mit Ver­knüp­fun­gen direkt zurück in den betref­fen­den Source Code). Sie kön­nen sich auch den Visu­al Tree, Ele­ment­ty­pen und Cache Updates anse­hen. Die Feh­ler­mel­dun­gen (zusam­men mit den Tipps für das wei­te­re Vor­ge­hen) und die Mög­lich­keit, auf der Suche nach Pro­ble­men in die Tie­fen der Anwen­dung vor­zu­sto­ßen, geben Ihnen die Mög­lich­keit, poten­zi­el­le Pro­blem­fel­der zu ent­de­cken und zu besei­ti­gen, bevor Sie die Anwen­dung zur Zer­ti­fi­zie­rung im Mar­ket­place ein­rei­chen.

Jetzt, wo Sie gese­hen haben, wie das Werk­zeug funk­tio­niert, sind hier noch ein paar Tipps um schnel­ler zu einer schnel­le­ren Anwen­dung zu kom­men:

  • Fan­gen Sie mit den Exe­cu­ti­on Per­for­mance Tests an um zu sehen, ob es mög­li­che Spei­cher­eng­päs­se gibt. Dies wür­den Sie im Spei­cher­ver­brauchs­dia­gramm erken­nen. Wenn Sie Pha­sen wäh­rend der Lauf­zeit der Anwen­dung haben, in denen die­se mehr als 90 MB Spei­cher ver­braucht, star­ten Sie den zwei­ten Test wel­cher sich spe­zi­ell auf Spei­cher­pro­ble­me kon­zen­triert. Sie wer­den fest­stel­len, dass alle ande­ren Pro­ble­me im Lauf­zeit­ver­hal­ten nor­ma­ler­wei­se mit dem ers­ten Test dia­gnos­ti­ziert wer­den kön­nen. Den zwei­ten brau­chen Sie nur, wenn die Daten im ers­ten Test die­sen spe­zi­el­len Test recht­fer­ti­gen.
  • Ver­ges­sen Sie nicht, Fast App­li­ca­ti­on Swit­ching, Tomb­s­to­ning und den ent­spre­chen­den Akti­vie­rungs­pro­zess zu tes­ten. Das sind wich­ti­ge Berei­che Ihrer Anwen­dung. Um das Tomb­s­to­ning in Ihrer Anwen­dung zu erzwin­gen, gehen Sie in die Eigen­schaf­ten des Pro­jekts und akti­vie­ren Sie auf dem Rei­ter Debug die Check­box „Tomb­stone upon deac­tiva­ti­on while debug­ging“. Andern­falls wird Ihre Anwen­dung nor­mal das Fast App­li­ca­ti­on Swit­ching nut­zen.
  • Machen Sie die Leis­tungs­ana­ly­se immer auf einem rea­len Gerät — die Leis­tung des Emu­la­tors ist nicht ver­gleich­bar mit der Leis­tung eines tat­säch­li­chen Geräts. Ein ech­tes Win­dows Pho­ne Gerät hat wesent­lich beschränk­te­re Res­sour­cen als ein nor­ma­ler Ent­wick­lungs-PC. Spei­cher- und Geschwin­dig­keits­pro­ble­me sind also auf einem ech­ten Gerät wahr­schein­li­cher als im Emu­la­tor. Die Aus­füh­rung der Tests auf einem ech­ten Gerät funk­tio­niert genau so wie das Debug­gen auf einem ech­ten Gerät. Ändern Sie ein­fach den Deploy­ment Tar­get von „Win­dows Pho­ne Emu­la­tor“ auf „Win­dows Pho­ne Device“ oben in der Visu­al Stu­dio Tool­bar.

Zusammenfassung

Hier sind eini­ge Links zu wei­te­ren Quel­len zur Win­dows Pho­ne Leis­tungs­ana­ly­se:

Mor­gen wird Gary John­son über Back­ground Agents schrei­ben. Wir wer­den sehen, wie wir die­ses neue Fea­ture in Win­dows Pho­ne 7.5 nut­zen kön­nen, um Code aus­zu­füh­ren auch wenn die Anwen­dung nicht läuft.

Bis dahin!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert