Sitter och testar prestanda mellan kod som är gjord i VBS med samma kod fast i VB och i en komponent.
Till min förvåning går det segare att köra komponentens kod. jag tycker att det borde vara tvärt om. Speciellt eftersom det är några tusen rader med kod.
Vilka delar är det egentligen man tjänar p åatt lägga i en komponent? Går ADO-hanteringen snabbare, eller är den lika seg som när VBS accessar den?
"Ren" VB/VBS-kod som innehåller loopar, matematiska operationer, jämförelser osv går vanligtvis mycket fortare i kompilerad/typad kod än i tolkad/otypad.
Anrop till extern (redan kompilerad) kod går inte nödvändigtvis fortare. ADO:n och OLEDB-drivisarna är ju säkert redan skrivna i högoptimerad C/C++. Om du anropar Connection.Open eller Connection.Execute från kompilerad eller tolkad kod ger ganska marginella skillnader. Du får en viss statisk vinst pga "early binding", vilket innebär att man slipper lokalisera addressen till funktionerna "run-time". Å andra sidan får du ytterligare ett lager som anropen måste passera igenom, med typkastningar fram och tillbaka till Varianter. Så det kanske jämnar ut sig?
Sammanfattningsvis:
Liten del av arbetet utförs i extern kod - Stor vinst.
Stor del av arbetet utförs extern kod - Liten vinst.
En JMail-komponent kan tex inte prata "fortare" med SMTP-servern för att man anropar den från assembler. Ungefär samma sak är det med ADO och databaser.
Okej, så min komponent borde egentligen gå snabbare da jag lagt in alla loopar och genereringen av klientkod i den.
Kan det vara att jag har ganska många properties? I VBS-koden var det väldigt många anrop till globala funktioner som jag inte kunnat lägga in komponenten, utan måste via properties ge värdet till komponenten.
Har det någon skillnad att jag kör i debuggläge (pilen i VB6)? Går det snabbare med en registrerad komponent?
Okej, så min komponent borde egentligen gå snabbare da jag lagt in alla loopar och genereringen av klientkod i den.
Ja, teoretiskt sett så ska det ju inte gå långsammare. Men sen beror det i hög grad på vad du gör inne i looparna. MoveNext och andra ADO-anrop tex går antagligen inte fortare i kompilerad kod.
Kan det vara att jag har ganska många properties? I VBS-koden var det väldigt många anrop till globala funktioner som jag inte kunnat lägga in komponenten, utan måste via properties ge värdet till komponenten.
Properties i sig, har jag svårt att tro att de är någon flaskhals. Att sätta en property är ju inget annat än att anropa en funktion? Sker det inte för ofta så ..
Har det någon skillnad att jag kör i debuggläge (pilen i VB6)? Går det snabbare med en registrerad komponent?
Vet inte riktigt. Skulle inte tro det. Vad du däremot kan göra när komponenten är avbuggad och klar är att gå in under Project->Properties->Compile->Advanced och slå av Bound-check och Overflow-check. Ibland kan detta ge hastighetsvinster iom att du slipper att kompilatorn slänger in en massa kod som du inte skrivit.
I övrigt så tror jag tyvärr inte du ska förvänta dig några gigantiska hastighetsvinster just när det gäller ADO/databas-grejer. Är du intresserad av det så bör du kanske titta på .NET och Output-cachning (för att slippa upprepad databas-access)?
Sant, det gjorde ingen skillnad att ha den registrerad.
Har gjort några Timer()-tester och funnit att instansieringen av objektet tar 0,02 sekunder. Att sätta alla properties tar 0,11 sekunder (detta fattar jag inte). Resten av tiden går åt att köra koden (0,14 sekunder, samma som när jag kör utan komponent).
Så 0,14 är fallet för båda metoderna, men med komponenten läggs 0,11 och 0,02 till och tar alltså längre tid,
Mycket av koden har hand om recordsets som ligger hos klienten. Så skillnaden borde inte vara så stor. Vad som är förbryllande är att det tar längre tid med komponenten.
Slutsatsen borde alltså vara att ur prestandasynpunkt så är en komponent i detta fall ingen bättre lösning, snarare sämre.
Det är väl lite missvisande att dra en sån slutsats, eftersom det hela beror på vad komponenten ska utföra. För just ditt fall verkar det ju däremot vara en sämre lösning ;)
Det är väl lite missvisande att dra en sån slutsats, eftersom det hela beror på vad komponenten ska utföra. För just ditt fall verkar det ju däremot vara en sämre lösning ;)
Vide skrev:
Slutsatsen borde alltså vara att ur prestandasynpunkt så är en komponent i detta fall ingen bättre lösning, snarare sämre.
Medhåll ifrån mig. ;)
Har det någon skillnad i vilken COM+ Application man registrerar komponenten?
In-Process Application, Out-Of-Process Application eller System Application?
Slutsatsen borde alltså vara att ur prestandasynpunkt så är en komponent i detta fall ingen bättre lösning, snarare sämre.
Tja, som sagt. ADO:en är ju redan en mängd högoptimerade och kompilerade komponenter/klasser skrivna i C++/C. Att "wrappa" dessa i en egen komponent ger kanske inte i sig någon hastighetsvinst. Utom möjligtvis om det är en stor mängd komplexa beräkningar. Dessutom tillkommer en statisk initialiseringskostnad (0,11 och 0,02 i ditt fall). Fördelarna med databaskomponenter är väl istället att man kan: dölja kod, återanvända kod, köra kod i transaktionsmiljö osv ..
Nackdelarna blir att det blir mycket bökigare att göra småändringar i redan kompilerad kod.
Dom gånger jag själv skrivit komponenter till ASP-sidor så har det varit just för att göra saker som man inte kan göra i VBScript: manipulera grafik, nätverksprylar, kommunicera med externa applikationer osv ..
Har det någon skillnad i vilken COM+ Application man registrerar komponenten?
In-Process Application, Out-Of-Process Application eller System Application?
Ja, Out-Of-Process Application blir i normalfallet ännu långsammare eftersom man måste skicka grejer över processgränser och eventuellt även över nätverket. I vissa fall så kan det så klart bli snabbare om den andra maskinen är kraftfullare. "System Application" har jag faktiskt inte ens hört talas om.
