Snelheid + Schaalbaarheid .Net & Delphi

Als Delphi programmeur was ik nog een beetje sceptisch over .Net, vooral mbt de snelheid. Hiervoor heb ik in Delphi een klein programmaatje gemaakt, wat in 2 for loops wat strings heen en weer kopieert. Dit heb ik gemaakt in een thread, zodat ik ook makkelijk met meerdere threads kon testen. Dit programmaatje heb ik met Delphi 2006 zowel native als met Delphi.Net gecompileerd.

Test resultaten: Win32 vs .Net
Resultaten op een Intel Core2 Duo (dual core dus), MS .Net 2.0:
Delphi.Win32:
1 thread = 3s
2 threads = 6s + 6s

Delphi.Net:
1 thread = 2s
2 threads = 4s + 4s

.Net is dus sneller dan native! Bovendien schalen ze allebei niet goed, want beide keren bleef de CPU steken op zo'n 50% (dus geen goed gebruik van dual core).

Test resultaten: TopMM
Standaard gebruikt Delphi 200X de FastMM memory manager. Ik had al eens eerder een andere gezien, die wel goed zou moeten schalen: TopMM (http://topsoftwaresite.nl/Downloads/TopMemoryManager22.zip).

Resultaten:
Delphi.Win32, TopMM:
1 thread = 6s
2 threads = 6s + 6s

Tja, nu schaalt hij heel mooi (beide cores op 100%) maar de performance is wel slechter...

FastMM fix
Benieuwd waarom TopMM wel goed schaalt en FastMM niet, zat ik in de code te duiken. FastMM gebruikt een lock voor de memory pool, terwijl TopMM per thread een aparte pool heeft (geen locks dus nodig). Als eerste heb ik de lock eruit gehaald: nu kwam de snelheid ook op 2s! Maar goed, voor meerdere threads is die lock wel nodig. Toen heb ik even snel een hack gemaakt voor FastMM door oa een "threadvar" te gebruiken, zodat elke thread zijn eigen pool krijgt. Nu hebben beide threads 2s en 100% CPU, oftewel: Delphi.Win32 is even snel als .Net, maar bovenal: het schaalt beter!

Multi cores: nadeel voor .Net
Het grote nadeel nu aan .Net is dat je dit niet makkelijk zelf kunt fixen, wat in Delphi.Win32 wel makkelijk kan. Vooral met het oog op steeds meer cores per CPU is dit een slecht punt voor MS .Net.

MS CLR shared code
Benieuw hoe in .Net oa de string allocatie is, kwam ik via het volgende artikel:
http://selvasamuel.wordpress.com/2008/03/14/boxingunboxing-in-net/
op het idee om in de CLR code van Microsoft te duiken. Via het "Shared source" initiatief van MS kan iedereen een gedeelte van oa de CLR downloaden (maar niet aanpassen etc!):

Shared Source Common Language Infrastructure 2.0 Release
http://www.microsoft.com/downloads/details.aspx?FamilyId=8C09FD61-3F26-4555-AE17-3121B4F51D4D&displaylang=en

Als eerste heb ik in de ".Net Reflector" (http://www.aisto.com/roeder/dotnet/Download.aspx?File=Reflector)
de code opgezocht van mijn thread. Aan de hand hiervan naar de functie gesprongen (door te klikken in de code) voor het kopiëren van strings: System.String.Copy. Deze maakt oa gebruik van "FastAllocateString":

Deze functie was als volgt gedeclareerd (in C#):
[MethodImpl(MethodImplOptions.InternalCall)]
private static extern string FastAllocateString(int length);

"InterCall" betekent dat het in de .Net CLR zelf geïmplementeerd is. Aan de hand van de shared code van MS van de CLR heb ik gezocht op "FastAllocateString". Deze functie wordt weer doorgelinkt van "ECall::FastAllocateString" naar "JIT_TrialAlloc::GenAllocString(flags)".
Hierin wordt net als FastMM een lock gebruikt. Helaas is deze lock niet makkelijk aan te fixen, oa omdat de Shared Source CLR niet compleet is.

AsmProfiler

Ontstaan

AsmProfiler is ontstaan naar aanleiding van mijn ontevredenheid over de profilers die ik gebruikt heb. Ik wilde oa meer details zien, en het moest makkelijk en snel in gebruik zijn. Via een oud-collega (Thaddy, nog bedankt!) kwam ik in aanraking met "detouring". Hiermee kon ik echter nog niet direct een profiler mee maken. Daarvoor heb ik zelf dmv assembly wat meer werk moeten doen. Dit gelukkig gelukt: mijn "proof of concept" werkte!

Werkbare versie, maar nog genoeg te doen...

In het afgelopen jaar heb ik in mijn vrije tijd het concept uitgebreid tot een redelijk werkbare versie. Nog lang al mijn ideeen zijn er niet in verwerkt, dus ik hoop nog veel functionaliteit toe te voegen! Verder is de documentatie nog niet in orde, en de code moet gerefactored/opgeschoond worden (ik heb al veel concept en "hackiediehack" :-) code verbeterd).

Open source

Ik heb het ontwikkeld met de "open source" gedachte: Ik heb zelf te weinig tijd om alles zelf te programmeren, en zelf vind ik dat elke programmeur zonder gedoe een profiler moet kunnen gebruiken. Dus bij deze wil ik iedereen oproepen om mee te helpen met het programmeren :-) .

Google Code

Het project heb ik bij "Google Code" gehost: http://code.google.com/p/asmprofiler/
Daar staan oa een wikki, issue tracker, download list, etc. Tevens regelt Google de opslag etc door middel van "Subversion" als versie beheer systeem. Lekker makkelijk voor mij dus. Wil je mee helpen met de code, dan zul je waarschijnlijk eerst moeten aanmelden, en ik moet je toegang geven tot mijn project. Maar dat zie ik dan wel weer, als er iemand is die belangstelling heeft :-) .

Asmprofiler demo

Ik heb naar aanleiding van een "klacht" op de DDD gelijk een klein demo project gemaakt :-) , dat toont hoe je AsmProfiler in een willekeurig Delphi project kunt gebruiken: http://asmprofiler.googlecode.com/files/DllLoadDemo.zip
http://asmprofiler.googlecode.com/files/DllTestApps.zip

Met C en C++ is het ook gewoon mogelijk om de dll te laden, hier heb ik echter geen C header file oid voor gemaakt. Die moet je zelf even maken adhv de Delphi interface unit.

Dll injection

Als je je programma niet wilt aanpassen, of als je de profiler wilt gebruiken op een programma waar je de code niet van hebt. dan kun de je de "injection" versie gebruiken: http://asmprofiler.googlecode.com/files/AsmProfiler_inject_v10011.zip

Start hiervoor de command line tool "inject.exe", zoek via de "Windows Task Manager" of "Process Explorer" de PID van een programma op, en voer die in. Druk op enter, en de dll wordt via officieele Windows APIs in het programma geinjecteerd :-) . Het scherm van de profiler wordt getoond zodra het geinjecteerde programma "GetMessage" of "Peekmessage" aanroept (normale Windows message loop). Echter, bij sommige programma's werkt dit niet, zoals Open Office.

Gebruik

Als je de profiler dll geladen hebt en het profiler scherm ziet, dan moet je eerst aangeven welke units en functies je wilt profilen door op de "Select items" knop te drukken:

Je krijgt dan een scherm te zien met alle units uit de .map file (Delphi -> Project options -> Linker -> Map file -> Detailed). Je kunt ook kiezen om alle (of bepaalde) functies van een geladen dll te selecteren:

Door op "Start" te drukken wordt het profilen gestart, de "Stop" knop stopt het monitoren :-) . Vervolgens kun je via "Show results" de resultaten bekijken:

Dubbelklikken op een item gaat naar het 2e tabblad met meer details.

Disclaimer

Uiteraard is het gebruik volledig op eigen risico :-) . Normaal gesproken moet het geen problemen geven, maar van bepaalde units weet ik dat sommige low level Delphi functies crashes veroorzaken... Zoals de "classes" unit bevat ook adressen naar (het begin van?) classes zelf ipv de functies van classes. Dit moet ik nog uitzoeken. Verder kun je beter de "system" unit ook vermijden: deze bevat veel low level functies. Het beste kun je je "eigen" units gebruiken, en de "Windows" unit is handig omdat het veel standaard Windows APIs bevat.

Delphi speed tips

Na mijn ".Net speed tips" kon een Delphi versie natuurlijk niet uitblijven :-).
Dus bij deze de eerste tips, een tweede (of meer) komen later.

Delphi IDE
De IDE van Delphi kan op een aantal manier versneld worden. Dit betreft de werking van IDE zelf, geen shortcuts etc.

- FastMM memory manager replacement voor Delphi
(http://sourceforge.net/projects/fastmm/)

De makers van FastMM hebben voor Delphi een "replacement dll" gemaakt, die het geheugen beheer van Delphi overneemt. Dit geldt dus alleen voor de Delphi IDE zelf, niet de gecompileerde applicaties (zie onder). Door "borlndmm.dll" te vervangen door de FastMM versie, is de IDE sneller en stabieler (!). Werkt van D5 tot D2005 (D2006 en hoger gebruiken zelf standaard al FastMM!).

- DelphiSpeedUp plugin
(http://andy.jgknet.de/dspeedup/)

Met deze plugin wordt de werking van de Delphi IDE een stuk versneld. Onder andere de opstarttijd is een stuk sneller, maar ook de algehele werking is sneller, doordat interne functies vervangen worden door functies van het Fastcode project (in geheugen, de Delphi .exe wordt niet aangepast). Verder heeft het allerlei interne caches en andere optimalisaties voor een snellere werking. Een echte aanrader!

Delphi experts
Delphi experts zijn plugins waarmee het leven van een programmeur gemakkelijk wordt :-).
Een kleine opsomming van mijn favorieten:

GExperts
(http://www.gexperts.org/tour/)

Dit is een zeer uitgebreide plugin, met zeer veel handige functies. De "experts" zijn verdeeld
over een aantal categorieen:
"Editor experts" - Bijvoorbeeld regels sorteren, reverse statement (!), previous/next identifier (begin/end etc).
"IDE enhancements" - Zoals multiline tabs, component palette verbeteringen.
"Code editor enhancements" - Multiline tabs voor open bestanden, editor toolbar.
"Editor toolbar" - Hierop kun je allerlei functies op plaatsen.

De extra functies die GExperts biedt lopen uiteen van een ASCII tabel tot een zeer goede "Grep
search", van "Set tab order" tot "replace components", van "Project option sets" tot "Project dependencies, van "Clipboard history" tot "Executable information". Verder gebruik ik de "Procedure list" functie erg vaak: CTRL-G indrukken en je krijgt een lijst van alle functies
die een Delphi unit bevat. Default is de subsearch actief: door een gedeelte van een naam in te typen wordt de lijst gefilterd, via "enter" wordt naar de functie gesprongen. Ideaal!

DDevExtensions plugin
(http://andy.jgknet.de/dspeedup/index.php?page=DDevExtensions)

Van de maker van de "DelphiSpeedUp plugin". Bevat een aantal kleine verbeteringen zoals een simpele progressbar tijdens compileren en een "component selector". Maar het meest gebruik ik de sterk verbeterde "View unit" en "View form" functies. Deze werken net als de "Procedure list" functie van GExperts. In dit geval gebruik je de normale CTRL-F12 en SHIFT-F12 sneltoetsen. In plaats van een simpele lijst waarin je alleen op het begin kunt zoeken, krijg je een mooie lijst die je kunt sorteren, filteren op classe, etc. Maar vooral super werkt subsearch: door een gedeelte van een unit/form naam in te typen, waardoor de lijst gefiltert wordt. Ideaal!

JEDI Experts
(http://homepages.codegear.com/jedi/jvcl/)

Deze zijn onderdeel van de JEDI componenten (JVCL, JCL). Deze bevatten een aantal debugger plugins (auto insert JEDI debug data in .exe, threadnames, etc), Project analyzer, Uses wizard etc.

.Net speed tips

Hoewel ik zelf (nog) geen ervaring heb met .Net, vindt ik optimalisaties altijd interresant,
maakt niet uit van wat. Aangezien het officieel .Net blog is (qua naam), kan ik op deze
manier ook wat meer .Net gerelateerde content plaatsen :-).

Speeding Up .NET
(allerlei kleine tips voor snelheidswinst)
http://www.codeguru.com/vb/gen/vb_misc/tips/article.php/c14049/

Strings UNDOCUMENTED
(StringBuilder efficienter dan Strings)
http://www.codeproject.com/dotnet/strings.asp

Arrays UNDOCUMENTED
(waarom one-dimensional arrays sneller zijn dan multi-dimensional)
http://www.codeproject.com/dotnet/arrays.asp

Wat specifieker, mbt Serialization:

Optimizing Serialization in .NET, part 1
http://www.codeproject.com/dotnet/FastSerializer.asp
Optimizing Serialization in .NET, part 2
http://www.codeproject.com/dotnet/OptimizingSerialization2.asp

Adv. debugging: Stack dumps met Process Explorer

In een eerder artikel heb ik uitgelegd hoe je zelf een stack dump kunt maken. Dit vooral bruikbaar bij exceptions, en soms ook voor het debuggen van een bepaalde situatie (”hoe komt hij hier?”).
Maar hoe kun je de stack bekijken als je programma vastloopt? In Delphi kun je het programma pauzeren en de stack bekijken, maar wat als het net buiten Delphi of op een (andere) server draait?

Process Explorer biedt dan uitkomst. Zoals ik al zei in een eerder artikel over Process Explorer: het is een super programma waar ik niet zonder kan. Je kunt er namelijk ook de stack mee bekijken van elke thread van een willekeurig programma. Dubbelklik hiervoor op een programma in de tree van Process Explorer en selecteer de “Threads” tab:

Dubbelklik vervolgens op een thread (hierboven is maar 1 thread) of klik op de “Stack” knop:

Het probleem is echter dat je dan geen beschrijvende namen ziet: alleen bijvoorbeeld een offset van 0×60664 bytes.

De truc hiervoor is om eerst een .map file te maken, en deze naar een .dbg file om te zetten:
Delphi -> Project Options -> Linker -> Map file -> Detailed
(zet ook eerst “optimization” UIT en “Stack frames” AAN op de compiler tab). Druk op “build” om opnieuw het programma te builden en om een map file te krijgen. Vervolgens moet van deze Delphi .map file omgezet worden naar een Windows debug file (.dbg).
Gebruik hiervoor “map2dbg”:
http://www.wischik.com/lu/programmer/ms-dbg.zip
Dit klein programmaatje moet via de command line (bijv. batch bestand) uitgevoerd worden:
map2dbg.exe .
Het bewuste programma wordt dan intern gemarkeerd dat het Windows Debug informatie bevat, en wordt omgezet naar .

Daarna moet in Process Explorer de directory als “symbol path” opgeven waar de bewuste .dbg file staat:
Options -> Configure Symbols

Als je dan een stack dump opvraagt, krijg je wel de volledige namen te zien:

Opmerking: map2dbg lijkt niet (altijd) te werken met Delphi 2007.
Bovenstaande demo lukte met 2007 niet en met Delphi 7 wel…

Soms heb je een nieuwe versie van “dbghelp.dll” en “imagehlp.dll” nodig:
http://msdl.microsoft.com/download/symbols/debuggers/dbg_x86_6.5.3.8.exe

“Now” functie is niet betrouwbaar! (ivm zomer/winter tijd)

In Delphi geeft de functie “Now” de lokale tijd terug. Dit is dus de gecorrigeerde tijd ten opzicht van de GMT of UTC tijd. Oftewel: de lokale tijd is de tijd rechtsonderin op de taakbalk.
Deze tijd is onderhevig aan zomer/winter tijd aanpassingen, wat al dan niet automatisch door Windows wordt aangepast…

Deze functie is dus niet betrouwbaar om de tijd te meten tussen 2 tijdstippen:
je hebt nl een kleine kans (van 2x 1 uur per jaar) dat de tijd 1 uur vooruit of achteruit verspringt ivm zomer/winter tijd. Vooral als kritische onderdelen van je programma hiervan gebruik maakt, is dit belangrijk om te weten!

Oplossing hiervoor is om gebruik te maken van de “GetSystemTime” API van Windows, en niet de “GetLocalTime” die voor “Now” gebruikt wordt.
Ik heb hiervoor een “NowUTC” functie gemaakt:

function NowUTC: TDatetime;
var
SystemTime: TSystemTime;
begin
GetSystemTime(SystemTime);
Result := SystemTimeToDateTime(SystemTime);
end;

Voor wat extra achtergrond informatie:

• Windows slaat zowieso intern alle tijden als “local” time op. Dus bestanden, logs, etc. Tijdens zomer/winter tijd wissel kan het dus voorkomen dat een bestand opeens 1 uur te oud of zelfs 1 uur te jong (in de toekomst) is! Zie KB van Microsoft:
  “Time stamp changes with daylight savings”
  http://support.microsoft.com/kb/q129574/

• De “SetLocalTime” API moet je 2x aanroepen om de PC tijd goed aan te passen. De eerste keer wordt nl de tijd eerst gecorrigeerd ten aanzien van de huidige tijd (dus 1 uur erop/eraf als je meer dan een half jaar veranderd) en kan dus 1 uur afwijken. De tweede keer zit je wel in goede winter/zomer tijd zone, en wordt de tijd wel goed gezet.
  Zie KB van Microsoft:
  “SetLocalTime/GetLocalTime Not the Same if Adjusting for Daylight Saving Time”
  http://support.microsoft.com/kb/q234735/
• Leuk om te melden dat Unix/Linux de tijd intern wel goed geregeld heeft:
  alles is intern GMT/UTC tijd, zodat het geen last heeft van de bovenstaande *kuch* features *kuch* van Windows. Zelfs Windows Vista heeft nog steeds de antieke en onbetrouwbare MS-DOS tijds bepaling! Meer informatie hierover:
  “IBM PC Real Time Clock should run in UT”
  http://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html

Instant Mantis: snel en direct een bug/issue tracking systeem opzetten

Een uitgebreid (!) verslag van een uit de hand gelopen experiment voor het gebruiken van een issue tracking systeem.

Het bedrijf
Ik ben nu dik 2,5 jaar bij hetzelfde bedrijf gedetacheerd, en in die tijd is het bedrijf (ondanks of dankzij ) flink gegroeid. Momenteel zitten we met 50 man in het nieuwe pand omdat het oude veel te klein werd. Niet alleen het bedrijf groeide, ook de projecten zelf groeiden (groter, ingewikkelder, etc).

Werkwijze
Wat niet direct mee groeide waren de werknemers zelf. Nog steeds wordt per project 1 status document in Word bijgehouden (groot, onoverzichtelijk, 1 persoon tegelijk wijzigen, etc). Nu worden daar voornamelijk mechanische dingen van de machines bijgehouden (aanpassingen), of klant/project gerelateerde zaken (wat besteld en geregeld moet worden). Want om alles van software bij te houden is een onbegonnen zaak.

Nu gaat dat meestal wel goed. De Voordelen van een klein bedrijf zijn de korte lijnen en de informele contacten. En de projecten waren nog te overzien. Er is een versie beheersysteem (Borland Starteam) en een eigen framework (met dank aan Aaldert ). Bij problemen wordt de programmeur in kwestie aangesproken: “Als ik dit en dat doe, doet ie het niet meer” -> “Oké, ik zal even debuggen en een nieuwe versie maken”. Echter, niet iedereen houdt consequent een “changelog” bij van wat er bij welke versie veranderd is.

Huidig project
Momenteel werk ik aan een machine die nu bij 2 klanten staat: 4 in Duitsland en 2 in Engeland. En op de zaak zelf staat een proto type (voor testen). De laatste tijd hield ik de meeste dingen bij in de email: “Ik heb een probleem”, “Kun je dit en dat even voor me doen of maken?” -> “Stuur maar een email, anders vergeet ik het”. In Outlook gaf ik dan een vlag aan emails die ik af moest handelen. Dingen die mij te binnen schoten, schreef ik op een kladblok, of hield ik in een draft e-mail bij. Maar met 2 klanten die al met de machine werken (dankzij “Agile development” in plaats van de “Waterfall methode” ) kreeg ik vaak de vraag (van projectleider) of iets al opgelost was, en zo ja in welke versie. Dankzij de changelog kon ik daar wel een antwoord opgeven, maar alleen ik had dus eigenlijk het overzicht.

Op zoek naar iets beters…
Natuurlijk wist ik wel dat het beter/anders kan en moest, maar je past je al gauw aan aan het bedrijf en komt in een bepaalde sleur vast te zitten (druk genoeg met programmeren, bug fixen, etc). Toen een nieuwe klant erbij kwam (in Nederland, met weer andere eisen & wensen) en de vakantie dichterbij kwam, werd het voor mij duidelijk: zo kan het niet meer, dit moet ik anders gaan doen. Ik ben toen op Internet wezen zoeken naar een bug/issue tracking systeem. Nu schrok ik een beetje van het aanbod: welke moest ik kiezen, en kon niet alles uitproberen (geen tijd). 1 naam kwam ik een aantal keren tegen, met goede recensies: Mantis. Op 1 site kreeg het zelfs een cijfer 9. Na wat zoeken op de site (http://www.mantisbt.org/) kwam ik “Instant Mantis” voor Windows tegen, wat precies voor mij geschikt was!

Instant Mantis
Mantis is een (open source) issue tracking systeem. Op site downloade ik gratis de 20mb zip, wat na uitpakken 70mb groot bleek te zijn. In de hoofddirectory vond ik 2 batchbestanden: 1 om te starten en 1 op te stoppen. Zo simpel is het. Bij het starten wordt automatisch MySQL (database) en Apache (website) gestart. Default start Apache op poort 8008, maar dit kon in het batch bestand eenvoudig aangepast worden naar 80. Firefox opgestart en ik kon direct aan de slag. Alles kan/moet via de webpagina ingesteld en aangepast worden: projecten, users, issues, etc.

Bugs en todo’s worden als “issues” ingevoerd. Hierbij kunnen de standaard velden ingevoerd worden: priority, severity, description, notes, attachments, status, etc. Er kunnen ook eenvoudig “custom fields” aangemaakt worden, bijvoorbeeld een required “customer” veld met een lijst van klanten waarvoor een issue geldt. Gebruikers krijgen automatisch een e-mail bij een nieuwe issue, en de “poster” krijgt e-mails terug als de status veranderd (fixed,feedback), notitie is toegevoegd, etc.

Acceptatie
Eerst wilde ik gewoon voor mezelf gebruiken en uitproberen. Ik liet het even vallen bij een (assistent) projectleider bij de klant op locatie (heeft VPN verbinding naar de zaak zelf). Deze was meteen geïnteresseerd en heb hem toen de computernaam opgegeven waarop het draaide (vmware build server). Na 1 dag proberen was hij helemaal enthousiast en moest voor hem ook de andere machines bij die klant als projecten toevoegen, en de nodige users voor die projecten. Hij kan precies zien welke bugs en todo’s openstaan, krijg bericht als iets in een volgende versie gefixed is, etc. Alles kan nu precies gevolgd worden (evt discussies via notes, extra info via attachments, automatische changelog voor een versie etc. Na nu een week draaien willen hij en ik niet meer anders :-). Steeds meer mensen gaan het nu gebruiken, en zijn enthousiast. Er is vorige jaar iets vergelijkbaars geprobeerd met T-Plan, maar dit beviel erg slecht: traag via VPN, onoverzichtelijk en onduidelijke GUI (op een label klikken om editbox te krijgen…) en te beperkt.

Huidige status
Na de vakantie heeft Mantis zich steeds verder verspreidt over het bedrijf. Ondertussen is het duidelijk geworden dat dit officiëler gebruikt moet gaan worden. In plaats van dat het draait op een van de vmware build/release images, moet het natuurlijk op een “echte” interne server draaien, en ook voor buitenaf via de website bereikbaar zijn (in plaats van alleen via VPN).

Toekomst
Voorlopig zal Mantis nog wel gebruikt worden :-). Het biedt bovendien perspectieven voor de toekomst. Er zijn namelijk verscheidene 3rd party koppelmogelijkheden zoals test management en project en release management. Bijvoorbeeld de test scripts worden in het test management pakket ingevoerd, en als een test faalt of opmerkingen zijn, dan worden deze als issues in Mantis ingevoerd en gekoppeld.
Maar het is ook mogelijk dat eerst een uitgebreid onderzoek gedaan wordt naar andere mogelijkheden, omdat Mantis 1 van de vele pakketten is. Voorlopig voldoet het echter prima.

Discussie
Hebben anderen ook dergelijke ervaringen? En wat gebruiken jullie zelf? Hebben jullie nog aanbevelingen of tips?