Som en del har märkt har det på allmänt i detta forum, under några dagar pågått en intensiv debatt om optimering av kod.

Främst är det peterh som hackat på Andreas Hillqvist för att han hela tiden rättar mina misstag. SvenPon har halkat in på ett bananskal också.

Andreas och SvenPon har haft synpunkter tillbaka på peterh:s sätt att koda.

Saken gäller följande:

peterh:
favoriserar lättläst kod som är enkel att förstå för andra som skall ta över och förvalta denna kod vid senare tillfälle. (Har nämligen debuggat alltför många C/C++ program som varit rätt dåligt kommenterade. VB-program likaså.) Denna kod exekveras av naturliga själ lite långsammare än den optimerade koden.

Anderas Hillqvist & SvenPon:
Favosriserar optimerad kod. Som alltid exekverar fortare, men ibland inte är lika lättläst. Ofta är den dock lätt att förstå. Denna kod tar dock som regel längre tid att klura fram. Men som van programmerare lär man sig snabbt. Dock tyvärr slarvar man nog mer ju mer van man blir, (vis av egen erfarenhet?).

Nu är frågan... Vad tycker ni andra på denna arean rent generellt: Gillar ni lättläst kod som alltid exekverar lite saktare, eller gillar ni optimerad kod som alltid exekverar fort och inte alltid behöver vara svår att förså.

PS. En sak till....
VB - är ju händelsestyrt. Den största tiden under de flesta programs livscykel är väntan, på att events skall triggas av användaren. Om vi nu antar för enkelhetens skull att ett program som exekverar skall läsa in en textfil på 667783 bytes i en sträng (win32api.txt) vilket på min maskin tog ca 27,07 ms i snitt på 500 inläsningar. Om denna inläsning skall triggas av eventet command1_click() innebär detta.. Jag lyckades inte göra en dubbelklick snabbare än 120 ms, på denna tid hinner ovan nämnda textfil läsas in 4,43 ggr. Asså jag har svårt för att få fram vad jag menar, men jag hoppas ni hajjar vad jag fiskar efter ;) Det jag egentligen menar.... Varför skall det gå så J---A fort att exekvera kod. Då den mesta tiden är väntetid för programmet. Det blir som i lumpen där man skämtsamt säger 90%-vila 10%-action. Men då saker händer skall det ske med en J---A fart. Är detta verkligen nödvändigt?

OK OPtimera kan man visst göra.. Sortering, ock så vidare, men då tycker jag det är befogat. Men även där blir det lite dumt. Det är liksom ingen vits att optimera en bubblesort för den blir aldrig snabbare än O(n^2), och det är liksom, typ iungen ide att beräkna fibonaci-serien rekursivt för den blir enormt slö för stora fibbonachital. Då tillämpar man andra metoder för att uppnå optimeringen. Nämligen MergeSort, QuickSort. binärträd och AVL-träd, hashing och andra trevliga datastrukturer och algoritmer.

Jag tycker att det liksom är onödigt att försöka optimera en snurra för att läsa in tio poster från en textfil bara för att tjäna 3 ms. När det sedan kanske tar 2 sekunder mellan olika events som skall exekvera koden i fråga.

Jag hoppas ni förstår och respekterar mitt resonemang.

Vad säger ni andra på detta forum....

Jag tycker dock ofta att det är intressant att se era slimmade optimerade lösningar. Det skall jag inte ta ifrån er.

Vill också bara berätta om en sak som hände i min dators ungdom... Eller jag menar då jag var nybörjare på datorer. Det var på den gamla goda C-64 tiden på det glada 80-talet. PÅ den tiden då man glatt hackade fram basic-spel och hackade fram snygga scrollrutiner i ren maskinkod. JAPP man satt och kodade på papper och översatte assemblerinstruktionerna till maskinkod och läste in detta i minnet.

Men det jag egentligen skulle säga var att i en tidning som fanns på den tiden DatorMagazin, fanns det varje månad en tävling där det gällde att skriva kortaste koden som utförde en viss uppgift. En gång skulle man skriva spelet masken, alla med NOKIA-telefon vet vad det är. Jag lyckades med en variant på endast 596 bytes (fattar ni vad otroligt lite detta var). Jag var bergis en vinnare (Trodde jag). När tidningen kom och jag skulle sola mig i äran att gjort minsta maskenspelet någonsin såg jag vinnarens bidrag. 119 bytes. Jag fattade inte ett skit av den koden. Men jag skrev in den och den funkade. Helt sanslös kod. Den var grotekst optimerad vad gällde storlek i alla fall. Min kod exekverade lika snabbt men den gick att förstå....

Nåja. Ha det bra....

Är det Piece nu, Andreas, SvenPon ?

>Vad tycker ni andra på denna arean rent generellt: Gillar ni lättläst kod som alltid exekverar lite saktare, eller gillar ni optimerad kod som alltid exekverar fort och inte alltid behöver vara svår att förså.

Väl kommenterad kod kan vara både snabb och förståelig.


>VB - är ju händelsestyrt. Den största tiden under de flesta programs livscykel är väntan, på att events skall triggas av användaren.

Nu verkar det som att du förutsätter att man bara skriver klientprogramvara i VB. Men det finns massor av VB kod som används på servrar, i DLL filer och på andra ställen där den aldrig syns. Så påståendet ovan gäller inte alltid.


Visst ska man optimera koden, men det gäller att veta vad man ska optimera. Det är oftast en liten del av koden i ett program som gör det största jobbet. Lägg krutet där, och ge resten lite lägre prioritet.

Ska du läsa in en fil var femte minut är det inte mycket mening att finslipa den delen. Ska du däremot göra det varje sekund kan det vara absolut nödvändigt.


MS

Tycker det är bra att du tar upp diskussionen.

Skulle vara intressant att höra vad dina lärare har att säga om Optimering.

DOM sade.....

Men ajajajaj nu har du gjort en bubblesort istället för mergesort.

Eller nu har du bara gjort ett binärträd--- Attans din slyngel du borde ha gjort ett AVL-träd, (Hör av dig om du inte vet vad ett AVL-träd är så skall jag förklara).

/peterh

> Ska du läsa in en fil var femte minut är det inte mycket mening att finslipa den delen. Ska du däremot göra det varje sekund kan det vara absolut nödvändigt.


Jamen jag gjorde ju ett program som läste in 650 kB på 20 ms varför vill du då att det skall gå snabbare om du skall läsa en fil varje sekund. Du hinner ju läsa in den filen 50 gånger per sekund. Om du hinner göra det 55 eller 45 spelar väl ingen roll eller ??

/peterh

Alltid trevligt med information, hittade en underbar sida tack vare din utmaning. Där bland annat AVL-trädet förklaras:
http://hissa.nist.gov/dads/

Är inte AVL-trädet fantastiskt... Gissar på att du redan sitter och hackar ihop ett eget ??

;) /Peterh

PS. Vilken utmaning snackar du om.... Jag har väl inte utmanat nån (har jag ?)

Nja... Utvecklar man databas applikationer i VB finns det inget större behov av det. Ligger ju i OLEDB providern och i andra komponenter som arbetar på en lägre nivå. VB är ju inte det optimala språket för att skriva sådana komponenter som hanterar det. Men det är mycket intressant.

Ser allt som en utmaning... :O)

Det är alltid intressant med Datastrukturer och Algoritmer... Men visst finns det alltid tillfällen då man måste använda sig av dessa flådiga strukturer.

Exvis Dubbellänkad lista om man nu gör ett program för att beräkna kortaste vägen mellan två geografiska punkter (shortest path) detta gör man med djikstras algoritm, den är groteskt finurlig. Den går kanske att implementera med ett AVL-träd...

Säg är du allmänt beläst inom data (Andreas Hillqvist) eller är du bara en självlärd hacker ??

/peterh

PS. Jag är beläst. Dataingenjör 120p. Inriktning lite mot hårdvarunära programmering. Så jag borde ju egentligen bara sitta och koda C/C++ men för nuvarande projekt duger det fanatiskt bra med VB för att kommunicera med kringutrustningen.

Djikstras algoritm beräknar väl kortaste vägen från en punkt till alla punkter. Finns väl bättre algoritm för att beräkna kortast väg mellan två punkter. (Snabb tolkning av informationen jag slog up. Måste säga det igen men siten http://hissa.nist.gov/dads/ är otroligt bra.)

:O)

Vill bara påpeka att i dagsläget är väl VB mindre lämpligt för att utföra dessa flådiga algoritm och data strukturer. Spännande att se hur lång tid det skulle ta att utföra en Djikstras algoritm i vb mot t.ex vb.NET, C++, C++.NET och C#. Kanske dags att skola om sig.

Är nog en självlärd hacker. Första kontakt med basic - vic20. Programmerat vb sedan win 3.11 och vb3.

Jag kanske skull läsa lite såndär hårdvarunära datautbildning.

OKI. Jag har fått en sån därn Visual STudio.net beta release men jag har inte testat den. Lite sugen på C#, men man har inte tid....

Det går alldeles utmärkt med Djikstras i VB... Det går fort....

Tja det beror på hur många noder det är i datastrukturen..

/peterh

Kan du inte skriva en artikel om hur man gör en Djikstras algoritm i VB?

Måste säga att du har ju helt missat vad man bör tänka på om någon ska underhålla ett program man skrivit. På följande adress finns all hjälp du behöver:

http://mindprod.com/unmain.html

/Christoffer

>Jamen jag gjorde ju ett program som läste in 650 kB på 20 ms varför vill du då att det skall gå snabbare om du skall läsa en fil varje sekund.

Jag syftade inte på just din 650 kb fil, utan mer generellt. Du kanske inte vet hur stor filen du ska behandla är. Du kanske inte vet hur snabb hårdvara det finns där programmet ska köras. Eller det kanske körs på en server tillsammans med en massa andra prestandakrävande applikationer som gör att ditt program snällt får vänta lite då och då.


MS

Skulle jag kunna göra.... Frågan är bara när.... Jobbar typ heltid och har ungar hemma så vi får se....

Men jag gör det gärna....

/peterh

Som de flesta redan sagt så beror det väl på situationen...

Lättläst kod behöver inte vara dålig kod, men man behöver ju inte ta det till några extrema nivåer.

Bra kommentarer och dokumentation så löser sig det mesta. Dock kan det vara ett rent helvete att försöka förstå program där man har optimerat och optimerat tills det knappt är någon kod kvar och ma nsitter där och kliar sig i huvudet och ska försöka dokumentera vad det eg. är programmet gör. Det är mycket sånt jag får sitta och ägna min tid som förvaltare åt.

Tog mig tex. 4 h att komma underfund med att en loop som jag satt och läste om och om igen eg. betydde "räkna ut hur många 13-veckors perioder som den här tidsperioden består av, men strunta i de fösta 13".
Den var grym..men fort gick den! (pratar iof inte om VBkod här men principen är detsamma)

Visst, hade det varit kommenterat så hade man kunnat förstå vad den gör, men problemet är att om det plötsligt skulle ändras så att man tex ville ha alla 12-veckors perioder så gick det inte bara att ändra 13 till 12 någonstans utan hela den lilla kodbiten måste göras om. Så i det fallet var optimeringen inte bra.

Grundregeln för alla optimering är väl ändå:
Jobba inte med koden, jobba med algoritmen. Om man har en situation där man skall läsa in en fil var 5:e minut så är kodoptimering inte så viktigt för farten, då är optimering gentemot storlek på koden viktigare (kompilerad storlek). Om situationen är att man skall läsa in data ofta och mycket då är det alltid den slöaste delen av algoritmen man skall attackera, sedan optimerar man sig vidare därifrån.

Sedan så tycker jag personligen att optimeringstips alltid är välkomna, man kanske inte behöver dom idag men man kan sitta i en situation där man behöver dom i morgon...

Hej
För mig är optimering en "mani",det sitter i sedan den tiden
man hade 125 k lagringsutrymme.

För mig betyder optimering minsta möjliga antal programrader
för att lösa ett problem.Det blir också oftast det snabbaste.

Brukar skoja med vissa här och fråga om dom får betalt betalt
efter hur många k programrader dom åstadkommer.

Det ser så ut ibland.
Det jag verkrilgen saknar i VB är att kunna implementera assemblerkod.

mv morgonhälsningar
Sven Som skall programmer tvättstugans knappar nu

Jag håller med om att det är så det ser ut ibland... Optimering = liten kod är inte sant iofs (om man skalar bort loopar i 8 och 16 bits arkitekturer kan man tjäna många klockcykler) men jag saknar också möjligheten till Inline assembler i VB.

Sven, om du mailar mig så kan jag dock bistå med information om hur du kompilerar ut en fungerande assembly av ett vb-program med "kommenterad" källkod och allt, denna kan man sen modda och kompilera med MASM.

Använd C/C++ om ni vill optimera så hårt!
Mycket effektivare klasshantering, inline assembly som standard, avancerad typkontroll utan prestandaförluster (för C++).

VB är inte gjort för att göra tidskritiska applikationer. Optimering behövs nästan bara för sånt som stör en användare.

/Niklas Jansson

Du har så rätt, men anledningen till att jag önskar inline asm i vb är att slippa gå utanför miljön för att tok-optimera ngt som ingår i ett större sammanhang (tex kalkylera och rita en graf baserad på stora mängder information). Dessutom har C++ en betydligt lägre utvecklingstakt än vb, iaf för mig och sannolikt 99% av alla andra vb-utvecklare (<= därmed inte sagt att mer än 1% av utvecklarna skulle ha nytta av inline asm).

Hej
>skalar bort loopar i 8 och 16 bits arkitekturer

Där har Vi en typisk grej som jag alltid reagerar på
I ett 32 bits system skall man bara använda Long
för heltal. De andra språken Delphi mfl kallar det
Integer som är det riktiga ,men där betyder det 4 byte(32 bitar)
.net har också tagit bort Long , kallas nu Integer.

Sven

Då kan du ju köra VB tillsammans med C++.

Utvecklingstakten är väl en fråga om vana.

Det låter lite väl att ta i om du skall optimera ett språk på mycket hög nivå direkt till den lägsta nivån du kan komma...

Just det exemplet du beskriver höll jag faktiskt på med en del till mitt specialarbete... det gick bra i VB, men då använde jag visserligen bara polynom och det beräknas rätt effektivt.

(Om någon vill veta så optimerar man bort alla upphöjningar och har bara en multiplikation per gradtal genom att man använder sig av att:

f(x)=ax^3+bx^2+cx+d= ((a*x+b)*x+c)*x+d

)

/Niklas Jansson

Hej
Där kom en optimerings detalj till
I Vb är det många många procent effektivare att
skriva 3*3*3*3 än att skriva 3^4

>Optimering behövs nästan bara för sånt som stör en användare.
Absolut en bra sammanfattning

DS