Sökte lite här på forumet och hittade att många förespråkar detta och påstår att det går "snabbare":
Set objRS = objConn.Execute(strSQL)
Do Until objRS.EOF
strNamn = objRS("namn")
strText = objRS("body")
strOP = strOP & strNamn & "<BR>" & strText & "<BR><BR>"
objRS.MoveNext
Loop
Set objRS = Nothing
Response.Write strOP
Alltså, att lägga allt som kommer från recordsetet i en variabel och sedan skriva ut variabeln.
Den här koden skriver ut posterna direkt med Response.Write istället för att lägga posterna i en variabel:
Set objRS = objConn.Execute(strSQL)
Do Until objRS.EOF
strNamn = objRS("namn")
strText = objRS("body")
Response.Write strNamn & "<BR>" & strText & "<BR><BR>"
objRS.MoveNext
Loop
Set objRS = Nothing
he, he ... det visar sig att den senare varianten är något snabbare med mindre processor tid än den första.
OK, inga stora skillnader ... bara typ ett par millisekunder, men den är ändå snabbare *ler*
Kollar man sedan in hur man hämtar recordsetet på för vis så är skillnaderna riktigt intressanta.
Med ADODB.Recordset som utgångspunkt så får man att:
recordset skapat genom Connection (i.e: Set objRS = objConn.Execute(strSQL)) objektet är ca 13% snabbare än genom ADODB.Recordset
och getRows() metoden är ca 40 % snabbare än genom ADODB.Recordset.
OBS!! öppnade ADODB.recordset på detta viset:
objRS.Open strSQL, objConn
alltså med default värdena.
Vad blir kontentan av dessa uppgifter?
Jo, gör hämtningarna med .GetRows() metoden och loopa sedan igenom arrayen.
Som sagt, att loopa genom en array eller ett recordset spelar ju ingen roll. Det är fortfarande en loopning det är frågan om.
visst får du det .... fast de är bara ca uppgifter. Finns mycket bättre sätt att testa. Men, tycker ändå att dessa är relativt korrekta. Använder man Webstress tools från MS så får man mycket bättre uppgifter.
Dessa uppgifter är gjorda med en enkle javascript funktion som hämtar en timestamp så att säga.
koden för timestamp:
<SCRIPT LANGUAGE=JScript RUNAT=Server>
function getMilliSec() {
var d = new Date();
return d.getTime()
}
</script>
Sedan gjorde jag en timestamp för start tiden precis innan jag initierade recordsetet och en timestamp för slut tiden när jag satt objRS = Nothing.
Exempel:
dteStartTime1 = getMilliSec()
strSQL = "SELECT Id, namn, [datum] FROM gastbok"
Set objRS = objConn.Execute(strSQL)
If objRS.EOF Then
Else
Do Until objRS.EOF
strNamn = objRS(1)
dteDatum = objRS(2)
Response.Write strNamn & ", " & dteDatum & "<BR>"
objRS.MoveNext
Loop
End If
objRS.Close
Set objRS = Nothing
dteEndTime1 = getMilliSec()
Response.Write (dteEndTime1 - dteStartTime1) & " ms."
Dessa tester jag utförde var mot en Access db med endast 25 poster i.
Gjorde precis liknande tester mot en annan db med ca 700 poster i och då vart skillnaderna mellan ADODB.Recordset hämtningen och hämtningen med Connection objectet endast 4% i skillnad och hör och häpna, .GetRows() metoden var hela ca 2,5 ggr snabbare än de andra metoderna.
OK, inte de perfektaste testresultaten, men man får en ganska snabb idee om vart exekveringstiden tar vägen med de olika metoderna
Förresten,
en intressant sak.
Lägger man till någonform av Paging så är det, hör och häpna, ADODB.Recordset som vinner. ca 20 % snabbare än om man använder sig av ngn annan typ av paging genom conn objektet, om man vill ha enpagebar som ser ut så här:
<< Föregående | 1 2 3 4 5 | Nästa >>
jo, det var intressanta resultat.
FAst som sagt ... getString har ju en MYCKET begränsat användningsområde.
Bra att använda vid enkel tabell struktur tex.
En annan intressant sak är hur många poster som hämtas. skillnaderna är mycket stora vid större posthanteringar.
cya,
PatrikB ... som inte är expert på detta ... ännu
provade du att använda Response.Write oxå istället för att bygga på en variabel som sedan printas ut?
Den går faktiskt ngt fortare ... ;p ... fast inte fortare än getString(), men de 2 andra alternativen du använt.
Har jag fattat det rätt om det är så här:
Tabell test
id | namn | epost
SQL = "SELECT * FROM test ORDER BY namn ASC"
set rs = connection.Execute(SQL)
arr = rs.GetRows()
for i = 0 to ubound(arr)
response.write "Namn: " & arr(1, i) & "E-post: " & arr(2, i)
response.write "<br>"
next
Nästan rätt... du måste ange vilken dimension du skall använda i Ubound:
SQL = "SELECT * FROM test ORDER BY namn ASC"
set rs = connection.Execute(SQL)
arr = rs.GetRows()
for i = 0 to ubound(arr,2)
response.write "Namn: " & arr(1, i) & "E-post: " & arr(2, i)
response.write "<br>"
next
provade du att använda Response.Write oxå istället för att bygga på en variabel som sedan printas ut?
Nope, jag är så van att inte blanda funktionskod med presentations kod. Och i detta test så skrev jag inte ut någonting... jag lade dem bara i variabler... Men visst det skall jag testa...
Om du flyttar ner intStart initieringen efter databasexekveringen, så får du ett bättre mätvärde, om det är åtkomsttiden man ska mäta.
Databasexekveringen kan ta olika tider, beroende på systemet. Det har jag själv råkat ut för.
Sedan bör (SKA) man använda en komponent för tidtagningen, eftersom scriptet i sig inte ger en korrekt tid, det är bättre att låta en separat komponent använda systemklockan. (nu kanske det är så du gjort iof)
/T
274 ms totalt · 4 externa anrop · v20260731065814-full.d34c6d5a
