Results 1 to 4 of 4

Thread: Is er een penalty op het gebruik van veel locale variabelen?

  1. #1
    Senior Member
    Join Date
    Mar 2002
    Location
    Edam
    Posts
    426

    Is er een penalty op het gebruik van veel locale variabelen?

    Hoi,

    Bij het bewerken van ( mijn eigen) oude code heb ik steeds meer de neiging om geneste statements om te zetten naar tijdelijk locale variabelen om de boel een beetje leesbaarder te maken. Het zal wel toenemende geestverstarring zijn maar ook als zo'n nest netjes is voorzien van commentaar wil ik (nu) graag het geheel gesplitst zien in afzonderlijke componenten/stappen.

    { haal het nummer op van de ontvanger }
    result := OntvangerNr(ReceiverType(BandSection(dataset.field byname('frequency').asfloat))));

    wordt dan;

    { haal het nummer op van de ontvanger }
    Frequentie := qry_personen.fieldbyname('Voornaam').asstring;
    Sectie := BandwidthSection(Frequentie);
    OntvangerType := ReceiverType(Sectie);
    OntvangerNr := OntvangerNr( Sectie );

    result := OntvangerNr ;

    In het algemeen zijn de procedures en functies niet heel repetitief of ingewikkeld en zal het hoe dan ook wel loslopen maar heeft dit in theorie nog invloed op de performance?

  2. #2
    Mijn gok is dat de parser hetzelfde doet als jij, dus dat er op de achtergrond 'locale' variabelen worden gemaakt (en mogelijk direct weer worden vrijgegeven?).
    Met de huidige geheugens zal het geen probleem zijn eigen locale variabelen te declareren en te gebruiken.
    Voordeel van de 'ont'nesting is de veel betere mogelijkheid van debuggen, nog afgezien van de leesbaarheid.

    Opmerking: zorg wel dat de uitgebreide regels dezelfde parameters en procedures hebben als de geneste regels. Anders wordt het een janboel

  3. #3
    In theorie kan het invloed hebben op de performance, maar in de praktijk zullen de nanoseconden die het scheelt, in het niets vallen bij andere dingen die je applicatie doet, zoals zo'n aanroep naar de database die je daar doet.

    En zelfs afgezien daarvan, is het gebruik van velden o.b.v. string naam al trager dan statische (design time gemaakte) velden. Een statisch veld als qry_personenVoornaam zal sneller te lezen zijn dan qry_personen.fieldbyname('Voornaam'), omdat voor die laatste de juiste veldindex bij de naam moet worden gezocht.

    Niet dat dát nou zoveel uitmaakt, maar mocht je toch een keer deze code sneller moeten maken, dan zit daar al meer winst dan in het schrappen van lokale variabelen. Je vraag is dus vooral academisch, er kán verschil zijn, maar dat ga je in de praktijk waarschijnlijk nooit merken.

    Ik ben er zelf overigens ook voorstander van om een extra variabele te gebruiken. Het is leesbaarder, maar ook veel makkelijker te debuggen en te refactoren.
    1+1=b

  4. #4
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Voor pointers en integers zal het erg weinig zijn. Voor automatische types komt er mogelijk netto wat refcounting overhead bij. De optimizer is minder goed in dat terugoptimalizeren. Een en ander hangt er weer wel vanaf of BandWidthSection een const parameter heeft of niet.

    Mij trof echter ook direct wat Goleztrol al zegt. In performance code acces je geen velden bij naam, je cached de veld indexen e.d, en beperkt string gebruik zoveel mogelijk. Strings zijn er alleen voor UI. Databases zijn ook tergend traag (een database access van 1ms is een eeuwigheid voor een CPU, want waarschijnlijk een orde grote miljoen trager dan simpele CPU instructies waar je het hier over hebt).

    Tot je echt dingen in een lusje miljoenen keren per seconde doet hoef je niet veel zorgen te maken, en zijn regels als database roundtrips beperken en zelfs onnodig string en variant gebruik te vermijden veel nuttiger dan dit uit optimalizeren.

    Ben je er toch geďnteresseerd, dan moet je er over na denken de gegenereerde assembler te bekijken en te leren evalueren.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •