wintertijd
HELSINKI - Zondag. Een uur vroeger.

Vrijdagavond begaf ik me met AC in het weekendse feestgedruis. In de stad was ergens een reggae-competitie, en ik had me laten overhalen die te bezoeken. *Helaas* was de rij voor het fraais nogal lang, net als de bossen ongewassen haar van veel der ongetwijfeld werkloze wachtenden ;-) Wij gingen verder naar wat andere bars, om tenslotte te eindigen in eentje vol met zonderlingen... Raar gekleed en opgemaakt. Duister en gothisch. Later realiseerde ik me dat het wellicht iets te maken heeft met Halloween...

Het ziet er overigens naar uit dat ik de komende tijd minder tijd heb om code te schrijven - mijn werk blijft erg technisch, maar programmeren zal wat meer een vrijetijdsbesteding zijn... nou ja. Nog steeds zijn er veel uitdagingen, en zoveel goede (en slechte) ideeën.

Zaterdag bekeken we Carlito's Way; aardige film met Al Pacino over een gangster (natuurlijk!) die ermee wil stoppen, na zijn vrijlating uit de gevangenis. En da's moeilijk - het beste is wellicht om een baan te zoeken in het buitenland, ver weg van de oude omgeving...

Deze week nog wat critical bugs weten op te lossen. We kregen een foutmelding (type 'hij doetut nie') over het versturen van mail via SMTP. Gelukkig is het hoofdkantoor van de ISP waar het probleem zich voordeed, slechts 100m van het mijne verwijderd, en ze waren erg behulpzaam. Sommige SMTP-servers interpreteren de RFC's nogal vrijzinnig (in dit geval het EHLO/HELO-commando). Toen ik het probleem kon reproduceren, was een oplossing snel gevonden - en hopelijk gaat het nu goed. Immers, wie weet welke andere SMTP-servers hun eigen interpretatie geven aan de MAY/SHOULD/MUST van RFC's. Ik probeer fundamentalistisch te zijn wat betreft de naleving - maar de 'echte wereld' vereist compromissen...

Deze week ook nog wat optimalisaties weten door te voeren, en anderen geholpen bij hun optimalisaties. Tijdens de implementatie van software moet natuurlijk wel aandacht besteed worden aan optimalisatie - geen 'domme' dingen doen, en geen ontwerp maken dat inherente performance-problemen heeft. Maar de nadruk moet erop liggen dat het ontwerp goed is, en de software correct functioneert. Daarna kan er geoptimaliseerd worden - en ik houd de volgende stappen aan:

• Neem een use-case; bijv., opstarten met 1000 berichten in mijn inbox is traag;
• Profileer deze use-case; (gebruik gprof, sysprof, oprofile en vrienden) om precieze gegevens te krijgen - waar zit al die traagheid? Concentreer je op dat trage deel, ga dat te lijf en vergeet de rest; 90% van de tijd wordt functie X uitgevoerd
• Nu komt het creatieve deel - verzin iets snellers! Soms moet een ander algoritme gekozen worden, soms worden onnodige dingen gedaan, etc. Belangrijk hier is om allereert het 'laaghangende fruit' te pakken.
• Profit! Toon het verschil in performance vóór en ná de verandering.

Wat ik soms zie is dat her en der in een project wat dingen worden gekozen die sub-optimaal klinken - uiteindelijk blijken die optimalisaties bijna niets op te leveren. En na de stappen (enkele malen) doorlopen te hebben, is er wellicht geen laaghangend fruit meer; of geen duidelijke 'brandhaarden'. Gefeliciteerd! Dan komen we in het volgende stadium van optimalisatie.

Voorbeeld van de week: ik een bepaalde use case bleek dat de meeste tijd werdt doorgebracht met het vullen van de rijen (in een GtkListView); voor elke rij wordt een gtk_list_store_insert en een gtk_list_store_set gedaan, en beide sturen een GSignal - en dat kost veel tijd (dank u sysprof!). Deze twee aanroepen zijn echter eenvoudig te combineren in een gtk_list_store_insert_with_values (dank u Jorn!). Dat kost slechts één GSignal, en dat leverde ongeveer 20% verbetering op! Geweldig, laaghangend fruit!

Het is goed te zien dat goede profiling-tools nu beschikbaar zijn voor Linux. Volgende stap is het geheugengebruik... Er zijn wel wat programma's, maar erg eenvoudig zijn die niet te gebruiken (ik sprak eerder al over smaps). Deze week ontdekte ik echter exmap, een programma dat ongeveer dezelfde informatie biedt als smaps, maar in een wat eenvoudiger formaat (te vergelijken met sysprof). Hopelijk kan daarmee ook de geheugenhonger van programma's te lijf worden gegaan. In ieder geval is exmap erg precies - geheugengebruik in kB, tot zes cijfers achter de komma!

-- djcb @ 18:10 | 0 comments