[VB] Applicatie is traag

[LuCarD]

Ik heb de grootte eer gekregen om een legacy applicatie te onderhouden en nieuwe ontwikkeling te programmeren.

Maar de applicatie is naar mijn gevoel onnodig traag. Nu wil ik weten of ik dat kan versnellen.

Dus mijn vraag is:
• Hoe kan ik er achter komen waarom de applicatie zo traag is? Bestaan daar leuke tools voor?

[ Voor 5% gewijzigd door LuCarD op 28-07-2003 16:42 ]

[Janoz]

Nope....

Dat wordt gewoon een kwestie van debuggen.

ff wat meer :

Probeer de trage stukken te indentificeren en isoleren en kijk waar dingen eventueel beter kunnen. Dat kan GUI dingen zijn, maar zou zoals hieronder aangegeven ook DB gerelateerd zijn.

Met mijn Nope bedoel ik dat een 'standaard tool' die het allemaal voor je doet er niet is. Daarvoor is het programmeren te divers. Je hebt echter vast wel tooltjes waarmee je geheugengebruik en timings uit kunt voeren.

[ Voor 80% gewijzigd door Janoz op 28-07-2003 16:47 ]

[Verwijderd]

met een Profiler? (weet niet of die er zijn voor VB),
wat voor applicatie is het?? Draait het tegen een database aan?
Misschien kan je de database monitoren, (rare query's , slechte indexen etc.).

hint:
http://www.google.nl/sear...=UTF-8&oe=UTF-8&hl=nl&lr=

[ Voor 19% gewijzigd door Verwijderd op 28-07-2003 16:44 ]

[LuCarD]

Janoz schreef op 28 juli 2003 @ 16:43:
Nope....

Dat wordt gewoon een kwestie van debuggen.

Met debuggen kan je niet zien hoe lang een stuk code erover duurt.

Verwijderd schreef op 28 juli 2003 @ 16:43:
met een Profiler? (weet niet of die er zijn voor VB),
wat voor applicatie is het?? Draait het tegen een database aan?
Misschien kan je de database monitoren, (rare query's , slechte indexen etc.).

Profiler?? Hmm zal een googlen

Het is een CRM applicatie, ik zal een wat performance logs aanmaken in SQL. Misschien dat daar wat uit komt.

[curry684]

Timestamped loggen doet meestal wonderen, oftewel bouw een Log-functie waar je een string aan mee kunt geven en die zelf gesynced in een logfile met timestamp schrijft, bijv.:

[Wed 29-07-03 13:43:02] Open database
[Wed 29-07-03 13:44:52] Schrijf data weg naar DB
[Wed 29-07-03 13:47:22] etc.

Zodra je hierin onverwacht grote tijdsspannes ziet kun je het betreffende blok verder opdelen om de performanceleak te vinden.

[Verwijderd]

LuCarD schreef op 28 July 2003 @ 16:46:
[...]
Het is een CRM applicatie,

Heeft toch niet te maken met:
nieuws: Microsoft brengt CRM-pakket naar Europa

[Edit]
Curry's methode werkt ook goed, zou je nog via een optie scherm aan/uit kunnen zetten. Kan je bij problemen altijd weer ff snel door de logs lopen.

[ Voor 27% gewijzigd door Verwijderd op 28-07-2003 16:51 ]

[curry684]

En zodra je release gaat builden commentariseer je natuurlijk de inhoud van de log-functie uit zodat je de rest van de code niet hoeft aan te passen

_{En nee ik kan nog steeds niet editen vanaf m'n werk dus vandaar 2 posts}

[Janoz]

LuCarD schreef op 28 July 2003 @ 16:46:
[...]


Met debuggen kan je niet zien hoe lang een stuk code erover duurt.

Ja hoor. Voor een stukje code de tijd opslaan, en erna kijken wat het verschil is met de huidige tijd. Als je dat bij verschillende stukken doet en dit enkele keren laat uitvoeren kun je precies zien welk onderdeel voor de vertraging zorgt.

[...]


Profiler?? Hmm zal een googlen

Het is een CRM applicatie, ik zal een wat performance logs aanmaken in SQL. Misschien dat daar wat uit komt.

Kijk eerst eens welke queries traag zijn en welke vaak worden uitgevoerd (waar vooral het laatste belangrijk is)

Een minime snelheids winst in code die vaak wordt uitgevoerd levert veel emer op dan een grote optimalizatie in code die weinig wordt uitgevoerd.

[curry684]

Een minime snelheids winst in code die vaak wordt uitgevoerd levert veel emer op dan een grote optimalizatie in code die weinig wordt uitgevoerd.

* curry684 heeft ooit een routine die zo'n 100000 keer werd aangeroepen in een bepaalde operatie ongeveer 40 keer (!!!!!!) sneller herschreven waardoor het geheel diverse malen sneller werd

[gorgi_19]

curry684 schreef op 28 July 2003 @ 16:49:
En zodra je release gaat builden commentariseer je natuurlijk de inhoud van de log-functie uit zodat je de rest van de code niet hoeft aan te passen

_{En nee ik kan nog steeds niet editen vanaf m'n werk dus vandaar 2 posts}

Dat niet alleen; als je bijvoorbeeld in VB.Net kijkt, werkt code als:

Visual Basic .NET:

#If DEBUG Then
    Globals.Trace("Defaultpage::LoadPane::Timer start", DateTime.Now.ToString)
#End If

Hiermee voer je alleen deze code uit in de debug mode; niet in de release mode. (Weet niet of dit ook in VB6 zit)

Janoz schreef op 28 juli 2003 @ 16:51:
Een minime snelheids winst in code die vaak wordt uitgevoerd levert veel emer op dan een grote optimalizatie in code die weinig wordt uitgevoerd.

* gorgi_19 kent ook zo een voorbeeld. Een kleine routine iets efficienter aanroepen --> parsetime van 1.12 sec naar 0.13 sec.

[ Voor 23% gewijzigd door gorgi_19 op 28-07-2003 16:56 ]

[Glimi]

curry684 schreef op 28 juli 2003 @ 16:53:
* curry684 heeft ooit een routine die zo'n 100000 keer werd aangeroepen in een bepaalde operatie ongeveer 40 keer (!!!!!!) sneller herschreven waardoor het geheel diverse malen sneller werd

40x sneller op wat? Op mijn computer? Jouw computer? Een dual Xeon?

edit:
Maw, tijd is niet de eenheid waarmee je wilt rekenen

[ Voor 8% gewijzigd door Glimi op 28-07-2003 16:56 ]

[gorgi_19]

Glimi schreef op 28 July 2003 @ 16:56:
[...]
40x sneller op wat? Op mijn computer? Jouw computer? Een dual Xeon?

edit:
Maw, tijd is niet de eenheid waarmee je wilt rekenen

Tijd is niet belangrijk in dit geval; wel het gegeven dat je door veel gebruikte stukken code efficienter te kunnen schrijven relatief veel tijdswinst kan boeken door een efficientere verwerking.
Het type computer maakt daarbij niet uit.

[curry684]

Als het op computer X 40 keer sneller wordt hoef ik het echt niet te benchen op 300 verschillende machines om de conclusie te trekken dat ik de routine goed geoptimaliseerd heb hoor

[Glimi]

curry684 schreef op 28 juli 2003 @ 17:01:
Als het op computer X 40 keer sneller wordt hoef ik het echt niet te benchen op 300 verschillende machines om de conclusie te trekken dat ik de routine goed geoptimaliseerd heb hoor

Niemand trekt de kwaliteit van jouw optimalisatie in twijfel. Echter die 40x sneller zegt zo bitter weinig.

[Verwijderd]

Gebruik zelf dit programma en werkt voortreffelijk.
http://www.microway.com.au/compuware/devpartner_studio.stm

[zneek]

Op welke database draait het? MS SQL Server? Dan kun je middels de SQL Profiler al een boel boven tafel krijgen. Die logt namelijk tijd e.d. per query/database actie. Je kijkt gewoon realtime naar alle acties op de database.

* zneek heeft daar al redelijk vaak rare bugs mee opgelost

[whoami]

gorgi_19 schreef op 28 juli 2003 @ 16:54:
[...]

Dat niet alleen; als je bijvoorbeeld in VB.Net kijkt, werkt code als:

Visual Basic .NET:

#If DEBUG Then
    Globals.Trace("Defaultpage::LoadPane::Timer start", DateTime.Now.ToString)
#End If

Hiermee voer je alleen deze code uit in de debug mode; niet in de release mode. (Weet niet of dit ook in VB6 zit)

Zijn dat geen conditional defines? Als je compiled in DEBUG mode, dan wordt die Globals.Trace regel meegecompileerd; compile je in release mode, dan wordt die regel niet mee-gecompileerd.

Met gewoon debuggen kan je toch al hier en daar zien wat er traag gaat.
Als die applicatie gebruik maakt van een database, dan kan je wellicht al heel wat snelheidswinst verkrijgen door ff te kijken of die database wel indexen bevat op de juiste kolommen. (Zorg ervoor dat er niet te veel en niet te weinig indexen zijn).
Je kan indexen leggen op columns waarop je veel filtert of joined.

Kijk ook eens welke types indexen jouw DBMS allemaal heeft. In SQL Server heb je bv. Clustered en Nonclustered indexes. Als je SQL Server gebruikt, dan kan je daar ook best eens naar kijken.
Een tabel kan wel slechts 1 clustered index hebben, aangezien die index ook de fysieke opslagvolgorde bepaalt. Een clustered index leg je best op een column waarvan je een ganse 'range' wilt selecteren.
(Meer over indexen: zie de P&W FAQ).

Als je samengestelde indexen gebruikt, zorg er dan voor dat het veld dat het meest unieke waarden bevat het eerste veld is in je index.

curry684 schreef op 28 July 2003 @ 16:49:
En zodra je release gaat builden commentariseer je natuurlijk de inhoud van de log-functie uit zodat je de rest van de code niet hoeft aan te passen

_{En nee ik kan nog steeds niet editen vanaf m'n werk dus vandaar 2 posts}

Of je maakt gebruik van conditional defines....

[ Voor 12% gewijzigd door whoami op 28-07-2003 17:51 ]