Håller på och går igenom min webbsidas aspkoder som inkluderas på varje sida.
Och nu har jag kommit till nyhetsdelen av sidan och undrar om det går att korta ner denna kod en bit eller förbättra den.
<%
i = 0
Set Connect1 = Server.CreateObject("ADODB.Connection")
Connect1.Open "driver={Microsoft Access Driver (*.mdb)};dbq=" & Server.Mappath("/database/nyheter.mdb")
Set RS = Server.CreateObject("ADODB.Recordset")
Addera1 = "SELECT * FROM nyheter order by id DESC"
RS.Open Addera1, Connect1
%> <% do while not rs.eof
i=i+1
if i <= 3 then %>
<img src="/top/pil.gif" width="9" height="10" border="0"> <b><a href=/news.asp?id=<%=RS("id")%>><%=RS("rubrik")%></a></b></br>
<%=RS("datum")%>
<p>
<%
end if
RS.MoveNext
Loop
RS.Close
Connect1.Close
%><br><b><a href="/aldrenyheter.asp">Äldre Nyheter</a></b>
Varför ta bort context-switchar när det gör koden tydligare och är effektivare än konkateneringar..?
Förbaskat bra fråga faktiskt.
För mig är det bara naturligt. När jag började med ASP för ett par dagar sedan, så var det bättre att konkatenera, so I was told. Jag får väl ändra mig, om det är bättre med contextswitchar.
Om vi då spinner vidare på frågan: Erik, hur gick det med din konkateneringsfunktion skulle vara så mycket bättre än att konkatenera med &?
niko: Tack för länkarna. Det känns dock som att man oftast jagar millisekunder på fel ställen, om man inte har en stor, konkateneringsintensiv applikation vill säga.
God programmerarvana.
Det blir för det mesta lättare att felsöka. Har även hört att variablerna hanteras lite snabbare om de är deklarerade, fast jag vet inte hur mycket sanning som ligger bakom det.
Om man dimmar variabler inne i funktioner/subbar så hjälper man så klart tolken på traven därför att den slipper undersöka om det redan finns en global variabel med samma namn. I annat fall är det väldigt svårt att förstå hur det skulle kunna ha nån betydelse.
@nders: Den la jag ner. Men när du säger att man jagar millisekunder på fel ställen så tycker jag det är konstigt att du börjat med konkatenering. För du gjorde väl det för att det ansågs vara snabbare..?
Sen så tycker jag inte bara man ska unvika konkatenering för att det är slött. Största anledningen till att undvika det är att koden ofta blir mer otydlig än om man använder context-switchar.
@nders: Den la jag ner. Men när du säger att man jagar millisekunder på fel ställen så tycker jag det är konstigt att du börjat med konkatenering. För du gjorde väl det för att det ansågs vara snabbare..?
Sen så tycker jag inte bara man ska unvika konkatenering för att det är slött. Största anledningen till att undvika det är att koden ofta blir mer otydlig än om man använder context-switchar.
Att jag börjat med konkatenering? Jag har konkatenerat för fulla muggar i mer eller mindre fem år, eftersom, ja, det sades mig att konkatenering av strängar är bättre än mängder av contextswitchar.
Tydlighetsaspekten har du helt rätt i, men man ska inte optimera ihjäl sig med sådana här småsaker.
Intressant tråd det här. Millisekundjakt är alltid skoj även om det kanske inte tillför användaren något Optimering börjar bli ännu intressantare vid hiskeliga klientsides-recordsets, som loopas och modifieras. Där kan man titta på andra bitar, som kan slöa ner.
Den där Catter, som niko länkade till ska däremot jag titta på... jag har nämligen en rekursiv funktion med åtta konkateneringar för varje anrop och normalt anropas funktionen 2800 ggr. Det borde gå att tjäna in tid där
Engine^ >>
Du har alltså 22400 (8*2800 ) konkateneringar?? Tabellen i min andra länk går bara upp till 2000, men om man extrapolerar så borde du kunna putsa bort ett par-tre veckor från din exekveringstid (om det är en och samma sträng).
Det är inte varje gång det konkateneras, men som värst har funktionen tagit cirka 4 ½ minut att köra
Jag har däremot tänkt till lite och har fått ner exekveringstiden till knappt 4 sekunder. Genom att inte använda konkatenering överhuvudtaget, utan pula in värden i en tabell istället... det fungerade bättre
.
