Torben Mogensen header

Bloat vokser hurtigere end computere

InfoWorld testede for nyligt forskellige versioner af Microsofts Office pakke på samtidige operativsystemer. Konklusionen var, at forøgelsen af både tid- og lagerforbrug oversteg udviklingen af en gennemsnitlig PC over den samme tidsramme. Med andre ord opleves Office pakken som langsommere og mere tung på en moderne maskine end på en syv år gammel maskine – hvis begge maskiner bruger den Office-version, der var den nyeste på det tidspunkt maskinen blev lavet.

Artiklen kalder udviklingen i bloat (et godt dansk ord, der betyder "oppustethed") for "The Great Moore's Law Compensator" med hentydning til Gordon Moore's udtalelse om den eksponentielle vækst i antallet af transistorer på en chip, hvilket ofte bliver tolket som eksponentiel vækst i computeres ydeevne. Groft sagt er meningen, at ressourceforbruget af almindelig software spiser alle forbedringer i ydeevne (og lidt til), som computere har fået gennem årene.

Windows og Office pakken er ikke de eneste syndere. Også open source software såsom Linux og Open Office bruger væsentligt flere ressourcer nu end for få år siden, selvom det er muligt at få Linux-installationer (f.eks. Puppy Linux og Xubuntu), der er rettet mod gammelt hardware.

Er det en uundgåelig udvikling?

En del af merforbruget skyldes større skærmopløsning på computere. En gennemsnitlig fem år gammel bærbar computer havde en skærmopløsning på 800x600 eller 1024x768, hvor moderne bærbare (når man ser bort fra Eee og andre miniputter) har 1280x1024 eller mere. Det betyder, at der skal vendes flere bit for at opdatere skærmen, og flere bit til at repræsentere skærmindholdet. Men det er næppe mere end en faktor to over de seneste fem år, så det er ikke hele forklaringen.

En anden faktor er, at brugerkravene er forøget. En browser skal for eksempel understøtte flere forskellige web-standarder end for fem år siden, og flere af disse standarder er også vokset i ressourcekrav. Det har dog ikke haft den store indflydelse på InfoWorlds test, da de samme *benchmarks *blev brugt til alle versioner.

Så tilbage er primært sjusk og feature creep, et andet godt dansk ord, der betyder at der ukritisk bliver hældt flere og flere features i applikationer, og at når de først er kommet ind, så ryger de ikke ud igen.

Og hverken sjusk eller feature creep er til gavn for de fleste forbrugere. De tilføjer bare mere uoverskuelig kode, som giver flere muligheder for hackere at finde sikkerhedshuller.

Evnen til at kode småt er åbenbart mestendels forsvundet, når man ser bort fra nogle få programmører af små indlejrede systemer. Meget få kan f.eks. lave kodekompakthed, der kan komme i nærheden af Rheolism, et Tetris spil, der er kodet i 256 bytes Basic. O.K., så ekstrem kompakthed er ikke ubetinget godt – det er f.eks. stort set umuligt at læse koden, men meget bloat kunne undværes, hvis programmører selv lavede to linjers kode i stedet for at kalde en biblioteksrutine, der tager 20 parametere og fylder en halv megabyte.

Kommentarer (10)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Dennis Krøger

Så tilbage er primært sjusk og feature creep, et andet godt dansk ord, der betyder at der ukritisk bliver hældt flere og flere features i applikationer, og at når de først er kommet ind, så ryger de ikke ud igen.

En stor del af grunden til de sindsygt mange features i Office programmer (MS og OO.org begge), er at de er så brugt til så mange forskellige opgaver, at der skal være "features til alle".

Det kan godt være at mange features kun bruges af 10%, men for mange af dem er det nødvendige features.

Andre features bruges så af andre 10%, og så fremdeles.

Der er ikke rigtig nogen vej udenom, hvis man vil have et generelt tekstbehandlings program, et generelt regneark o.s.v., og de samtidig skal følge med de nye anvendelsesområder og -måder der kommer hen ad vejen.

  • 0
  • 0
#2 Søren Hilmer

Er da vist "en vej udenom". Hvis disse programmer kom med et godt plugin system, kunne specielle features loades som plugins for dem der har behov for dem, og dermed reducere den generelle bloat.

  • 0
  • 0
#3 Jacob Christian Munch-Andersen

Selvfølgelig fylder flere funktioner mere, men de fleste funktioner burde altså kunne klares på nogle få byte. Vi er vant til at man stort set ikke kan få en executeable på under 1 MB, men sandheden er at det at fylde 1 MB med brugbar kompileret kode er en umenneskeligt stor opgave. Du kan fint skrive en fuldt funktionsdygtig tekst editor på 10 kB, og har du i stedet 1 MB kan du fylde et utal af features på. Folk har en tendens til at tro at bare fordi en enkelt MB fra eller til er så ubetydelig for dem selv så kan den nok heller ikke bruges til særligt meget.

  • 0
  • 0
#5 Anders Olsen

{quote} gså open source software såsom Linux Linux og Open Office bruger væsentligt flere ressourcer nu end for få år siden {/quote} Hmm. Jeg så en benchmark, der viste at Ubuntu 7.04 faktisk var et par procent hurtigere end den noget ældre 6.06 på samme hardware. Den nye 8.04 skulle være faldet et par % tilbage igen på identisk hardware, men altså ikke noget der skulle kunne æde Moore-forøgelsen.

  • 0
  • 0
#6 Søren Hilmer

Er det ikke kun fordi det moderne kontorprogram i forvejen er bloat'et?

Tag fx en feature som WordArt, det bruger jeg aldrig og det kunne passende være en plugin, og jeg tror ikke den er særlig resource mæssigt "tynd".

  • 0
  • 0
#7 Jacob Christian Munch-Andersen

WordArt er nok en af de funktioner der kan sluge en anelse mere end så meget andet, men altså selve koden behøver stadigvæk ikke at være mere end et overskueligt antal kB, de grafiske elementer som genereres fylder selvfølgelig noget, men de ryger under alle omstændigheder først ind i rammen når de tages i brug.

Pointen er at der overhovedet ikke er brug for at fjerne features, langt størstedelen af bloaten kunne undgås ved bedre kodning.

  • 0
  • 0
#8 Morten Juhl-Johansen Zölde-Fejér

Abiword og Gnumeric er gode eksempler på et ret solidt produkt, der ikke er så voldsomt stort - og i hvert fald Abiword lader sig jo udvide med plugins. Det er interessant, synes jeg - jeg er helt enig i, at en betragtelig del af funktionsmassen bør foreligge som plugins. Jeg sætter for eksempel meget pris på bibliografi-funktionen i OOo, men det var ikke strengt nødvendigt, at det er en del af programmet! Og det fører jo videre til "standing on the shoulders of giants"-argumentet: Med så omfattende et program - eller system, kunne man måske sige - er det jo ikke så nemt at rive tingene UD igen.

  • 0
  • 0
#9 Erik Martino Hansen

En af synderne er swap. Når nu der ikke er en rigtig øvre grænse på mængden af hukommelse har man som udvikler en tendens til at bruge løs.

Er det noget som udviklere typisk har, er det maskiner med masser af RAM og masser af CPU. De mærker derfor ikke selv problemerne.

Engang fandes der computerblade med konkurrencer i at lave de bedste programmer på kun 20 liniers basic. Det kunne der komme spil med musik og fin grafik ud af. Der var bootblock demo konkurrencer på Amigaen hvor man skulle imponere mest muligt med 1024 bytes maskinkode og data. Den slags burde man måske gøre noget mere i på læreanstalterne.

  • 0
  • 0
#10 Dennis Decker Jensen

Moore's lov knaekkede i 2003, og forbruget af RAM er nu saa stort, at cachen (L1 og L2) laenge har vaeret flaskehalse, saa faktisk kan vi i de kommende aar formentlig komme til at se en slags tilbagevenden til de glade 1970'ere, hvor man havde behov for at kunne optimere den slags.

Men som allerede beroert i andre kommentarer, saa er de haarde kompetencer desvaerre gledet ud. De kan naturlig genvindes med en indsats igen, men betyder det, at bloat vil forsvinde? Intet tyder desvaerre paa det. Der vil stadig komme flere og flere middelmaadige programmoerer, og saa vil feature creep sikkert vaere nogenlunde proportional med bloat.

Hvem kan huske komplette systemer som Oberon (styresystem med netvaerk, mail, etc. paa ca. 200 Kb.), der kunne ligge paa en diskette? Og "store" (dengang store) Smalltalk-programmer, som fyldte 1 Mb. er jo pinligt smaa i dag, ikke sandt?

Jeg er pessimist. Jeg ved det kan goeres bedre, men omstaendighederne konspirerer imod det.

/Dennis

  • 0
  • 0
Log ind eller Opret konto for at kommentere