mboost-dp1
Windows "sander til"
fidomuh (247) skrev:#XorpiZ
Ja.
Der er ret stor forskel paa 1 og 2 minutter.
Jeg ved godt at folk ikke har nogen tidsfornemmelse idag, men jeg kan godt taelle fra 1 til 120.
Man kan godt have sine tvivl til tider. Men fortæl endelig - hvilket program brugte du, hvilke andre optimeringer kørte du, osv.?
fidomuh (247) skrev:Det mener jeg ikke, jeg har givet udtryk for. Jeg har derimod skrevet, at der ikke er noget, der peger på, at det giver en målbar forskel, men at jeg er villig til at lade mig overbevise, hvis nogen kan bevise en forskel.
Ih ja, det er nemlig det samme som at 'eksperter' paastaar der ikke er en forskel.
Og ja, du tog fejl.
Igen, der er *RIGTIGT* mange der har samme opfattelse som mig.
#244
Tak fordi du gad at proeve :)
Jeg tog fejl med NT RegOpt -.- Det har jo intet med sagen at gøre. Hvis du læste hvad der stod, ville du se, at RegOpt _ikke_ er en decideret cleaner. Den ændrer ikke i reg.db.
Hvem er de "*RIGTIGT* mange", der deler din opfattelse? Du gik fra dig og din mor til RIGTIGT mange, bare sådan, uden at fortælle hvad du gjorde, hvorfor du gjorde og hvordan du gjorde det. Forventer du, at jeg skal tage det seriøst?
Jeg er ikke i tvivl om at NT RegOpt sagtens kan have en effekt - det er bare ikke det vi snakker om.
Og jeg opsummerer lige én gang til for dig:
1. Der er ingen beviser for, at reg. cleaners har en performance-effekt
2. Flere anerkendte eksperter siger direkte at reg.cleaners ikke har en målbar effekt
3. Dine "beviser" er, at du engang i tidernes morgen nedskar boottiden med 1 minut på din eller din mors maskine (men ikke et ord om hvad du gjorde)
Og btw; at kalde Mark Russinovich for en 'ekspert' er grænsende til det ignorante.
themuss (252) skrev:n00bs! min windows booter på -26 sekunder.
Er der en fix til det, jeg hader at min computer altid booter før jeg tænder den og derfor lukker ned når jeg trykker på power.
Ehh fix? Jeg kan afsløre du skal planlægge din pc-tid nøje, men tror ikke du har l33tnees nok til at wielde en computer der booter hurtigere end tiden :)Jakob Jakobsen (254) skrev:Er der en fix til det, jeg hader at min computer altid booter før jeg tænder den og derfor lukker ned når jeg trykker på power.
@windcape
Bliver nødt til lige at rette den påstand du er kommet med flere gange i løbet af tråden (ja, har læst det hele):
Hvis du fjerner evolution, fjerner den ganske rigtigt ubuntu-desktop pakken, men det er en såkaldt metapakke, så du fjerner ikke gnome, men ubuntu-desktop er afhængig af f.eks. evolution og gnome. Så for at den kan eksistere skal begge dele være til stede.
Det betyder ikke at den afinstallerer alle pakker der er i ubuntu-desktop, men at den fjerner meta pakken, for nu har du ikke en "ren" ubuntu-desktop mere, men i stedet 99% af den (ubuntu-desktop minus evolution).
Bliver nødt til lige at rette den påstand du er kommet med flere gange i løbet af tråden (ja, har læst det hele):
Hvis du fjerner evolution, fjerner den ganske rigtigt ubuntu-desktop pakken, men det er en såkaldt metapakke, så du fjerner ikke gnome, men ubuntu-desktop er afhængig af f.eks. evolution og gnome. Så for at den kan eksistere skal begge dele være til stede.
Det betyder ikke at den afinstallerer alle pakker der er i ubuntu-desktop, men at den fjerner meta pakken, for nu har du ikke en "ren" ubuntu-desktop mere, men i stedet 99% af den (ubuntu-desktop minus evolution).
Jeg har lige opgraderet til 10.04. Jeg har afinstalleret alle evolution pakker på nær evolution-data-server-common da:
Ellers kan man godt fjerne alt evolution. dvs :
evolution, evolution-common, evolution-data-server, evolution-webcal, evolution-plugins
Dermed er det faktisk væk.
Jeg vil bare mene at der er lidt fjollet at evolution-data-server-common ikke bare hedder data-server-common. Så ville der ikke være noget problem.
# apt-get remove evolution-data-server-common
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
evolution-data-server-common gnome-applets gnome-panel gnome-session indicator-applet indicator-applet-session indicator-me libedataserverui1.2-8
ubuntu-desktop
0 upgraded, 0 newly installed, 9 to remove and 0 not upgraded.
After this operation, 14,0MB disk space will be freed.
Do you want to continue [Y/n]? n
Abort.
Ellers kan man godt fjerne alt evolution. dvs :
evolution, evolution-common, evolution-data-server, evolution-webcal, evolution-plugins
Dermed er det faktisk væk.
Jeg vil bare mene at der er lidt fjollet at evolution-data-server-common ikke bare hedder data-server-common. Så ville der ikke være noget problem.
Ubuntu 10.04 på Intel Core 2 Quad Q9300 @ 2.50GHz + Intel X25-M SSD
ink. manuel logon booter på 40 sek. fra kold start.
ink. manuel logon booter på 40 sek. fra kold start.
Windcape (107) skrev:Ikke enig. Jeg kender mange som ikke bruger standard-shell på Windows XP.
Jeg har en stærk mistanke om, at de kører oven på ikke ved siden af Windows GUI.
Men det er jo nemt at afgøre. Virker de på 2008 Core ?
Windcape (107) skrev:Og det er bestemt ikke simpelt at installere KDE på en Ubuntu der allerede kører med GNOME!
Nu kender jeg ikke Ubuntu. Men på Redhat baserede distroer, så sætter man flueben ved begge i installeren og på login skærmen er der en menu for at vælge den man vil have.
plazm (128) skrev:#124, skrev jeg linux kernen, tror jeg ikke http://en.wikipedia.org/wiki/Linux
http://en.wikipedia.org/wiki/Operating_system
og kom nu for pokker ikke med at wikipedia er en ringe kilde...
Linux projektet som Linux Torvalds leder er kun en kerne.
Linux som bred betegnelse brugt i Computer World er et OS og dækker over Linux kernen plus en stribe apps som "normalt" er til stede sammen med Linux kernen bl.a. en hel del GNU stuff.
Windcape (148) skrev:Du kan også bare opgradere Windows til Windows 7.
Det koster jo så penge.
Windcape (148) skrev:Hvis du ikke vil argumentere med det nyeste af det nyeste, mod det nyeste af det nyeste, så må du jo acceptere at vi bringer gammel lort ind i diskussionen.
Der er en vis forskel.
Der er rigtigt mange som bruger Windows XP.
Der er ikke ret mange som bruger Linux versioner tilbage far 2002.
Det er vel rimeligt at sammenligne det som folk faktisk bruger?
røvskæg (156) skrev:Desuden er defragmentering er ikke nødvendig med ext3/4. Default Ubuntu filsystem.
Det kan Linux folk godt lide at bilde sig selv ind.
Men det er noget pladder.
Ved visse brugs mønstre bliver en fil lagt i ikke contigious klumper og det vil give anledning til seek operationer som tager tid.
SlettetBruger (158) skrev:Arh jeg må nu også sige det er retarderet at hvis vi skal sammenligne XP fra 99'erne med at andet styresystem, så skal det sku også være fra den generation.
XP er fra 2002.
Men du må gerne angive en Linux distro version fra 2002 med en andel på ca. 1/2 af alle Linux brugere som vi kan sammenligne med!
:-)
XorpiZ (160) skrev:Det der er retarderet er når man begynder at foretage en seriøs sammenligning af et OS, der er 3 måneder gammelt (hint: Ubuntu 10.04) med et, der er snart 10 år gammelt (hint: Windows XP).
Det er vel mest relevant at sammenligne de Windows versioner som folk faktisk kører med de Ubuntu versioner som folk faktisk kører?
XorpiZ (175) skrev:Desuden, nu vi er i sving, så vil jeg da gerne se dine beviser for, at registreringsdatabasen er skyld i, at XP bliver langsommere og langsommere.
Det er nok svært at bevise.
Men vil du ike tro, at den gennemsnitlige Windows maskine har en masse junk i registry specielt relateret til COM?
Og at både antallet af entries i sig selv plus referancer til COM komponenter som mangler vil have en negativ effekt på performance?
XorpiZ (179) skrev:I øvrigt kan det nævnes, at Mark Russinovich (som du måske kender?) kraftigt anbefaler, at man holder fingrene fra registry-cleaners, fordi de ikke giver ekstra performance og potentielt kan ødelægge ens Windows-installation.
Nu tror jeg ikke at han anbefaler hverken overflødige entries eller invalide entries i registry.
Han har nok bar en stor skepsis overfor kvaliteten af programmer der skal rydde op.
Af gode grunde. Jeg tror ikke på at der kan laves en 100% sikker og effektiv oprydning i registry.
XorpiZ (189) skrev:Jeg savner dog stadig noget som helst bevis for, at det skulle gavne at køre f.eks. CCleaners Registry-tool.
Det er sikkert ikke nok til at det er målbart.
Hvis den sletter 300 entries ud af 300000 entries er det ligesom ikke nok til at give noget.
Men vokser antal entries fra 300000 til 400000, så kan det sikkert mærkes.
Man må antage at registry access er O(logn).
XorpiZ (204) skrev:
Sandt - men når nu Mark Russinovich (der om nogen må være en ekspert på området) direkte udtaler:
"No, even if the registry was massively bloated there would be little impact on the performance of anything other than exhaustive searches. "
så har jeg svært ved at tro andet. :)
Tror du at registry access er O(logn) eller O(1) ?
Hvis Russinovich kan lave en O(1) database, så spilder han hans tid på Windows tools - han skal over i SQLServer teamet flux.
XorpiZ (206) skrev:Ydermere, så er der flere hundrede tusinde keys i databasen - skulle det virkelig hjælpe at fjerne 50-100-150 "defekte" keys?
Så få keys har næppe nogen effekt alene udfra størrelsen af registruy databasen.
Hvis de får Windows til at forsøge at loade en fil der ikke er der, så koster de dyrt.
Skak2000 (211) skrev:
Man kan håbe på Microsoft arbejder på at få skiftet registrerings databasen ud... Opgaven er tydeligvis enorm...
Måske er det bedre de starter på en frisk, med at bygge det op fra grunden?
Det startede de på i 2002.
.NET apps bruger (normalt) ikke registry.
terracide (89) skrev:Jeg er ved at tro at det ikke er windows der er problemet, men folk der installere al muligt 3. parts lort...og derefter skyder skylden på windows.
Hvis problemerne med det 3. parts lort er at det bruger Microsofts anbefalede måder (1995-2002) at integrere apps med Windows på, så er det jo et Windows problem.
arne_v (275) skrev:XorpiZ (204) skrev:
Sandt - men når nu Mark Russinovich (der om nogen må være en ekspert på området) direkte udtaler:
"No, even if the registry was massively bloated there would be little impact on the performance of anything other than exhaustive searches. "
så har jeg svært ved at tro andet. :)
Tror du at registry access er O(logn) eller O(1) ?
Hvis Russinovich kan lave en O(1) database, så spilder han hans tid på Windows tools - han skal over i SQLServer teamet flux.
Jeg ved ikke hvad O(logn) og O(1) dækker over. Matematik er ikke min stærke side - men jeg går ud fra, at det betyder noget i stil med, at søgetiden stiger ekspotionelt og ikke lineært, jo mere data, der ryger ind?
Nu er jeg ude i spekulation, men det må være fair at antage at en key kun bliver brugt, hvis et program kalder den. Altså må risikoen for at en reg-key kalder en fil, der ikke findes, være ret lille (medmindre man med vilje ødelægger en installation).
Og jo, en gennemsnitlig Windows-bruger har formentlig en masse entries, der ikke er i brug eller er blevet efterladt. Jeg kan bare ikke forestille mig, at det er noget, der har en effekt på ens performance.
Som sagt, så er jeg villig til at lade mig modbevise dog.
Hov, og ang. Windows XP/Ubuntu-tingen. Jeg synes ikke det er fair at sammenligne. Det svarer vel til at sammenligne Nokia en-eller-anden-gammel-model, som alle har og en iPhone, og så sige, at Nokiaen er sløv og mangler features. Det er som sådan rigtigt nok, det giver bare ikke rigtig mening.
#279
Det betyder at søgetiden stiger logaritmisk (langsommere end lineært) O(lgn), eller søgetiden er konstant, O(1).
Det betyder at søgetiden stiger logaritmisk (langsommere end lineært) O(lgn), eller søgetiden er konstant, O(1).
#280 Eller lidt mere konkret (måske):
En database har 1024 keys. Et opslag efter een key tager så: lg (1024) = 10 tidsenheder (i eksemplet er brugt base 2)
Vi skalerer nu mængden af data op til opslagstiden er fordoblet. Hvad er antallet af keys?
1024 keys = 10 tidsenheder
Ved at skalere antallet af keys får vi flg. formel:
20 = lg (x * 1024 keys)
Hvilket kan omskrives til
=> lg (x) + lg (1024)
lg (1024) kender vi svaret på, nemlig 10, så vi kan reducere til:
10 = lg (x)
Hvilket vi også kender svaret til, nemlig: x = 1024.
Vi har nu at data-sættet skal være en faktor 1024 større for at et opslag tager dobbelt så lang tid.
Samme regnestykke med 1,5 i stedet for:
15 = lg (x * 1024)
=> 5 = lg (x)
2^5 = x
x = 32
Dvs. at for at forskellen mellem ZiN's (#205) bloatede DB og den normale skal være en faktor 32 for at holde vand.
En database har 1024 keys. Et opslag efter een key tager så: lg (1024) = 10 tidsenheder (i eksemplet er brugt base 2)
Vi skalerer nu mængden af data op til opslagstiden er fordoblet. Hvad er antallet af keys?
1024 keys = 10 tidsenheder
Ved at skalere antallet af keys får vi flg. formel:
20 = lg (x * 1024 keys)
Hvilket kan omskrives til
=> lg (x) + lg (1024)
lg (1024) kender vi svaret på, nemlig 10, så vi kan reducere til:
10 = lg (x)
Hvilket vi også kender svaret til, nemlig: x = 1024.
Vi har nu at data-sættet skal være en faktor 1024 større for at et opslag tager dobbelt så lang tid.
Samme regnestykke med 1,5 i stedet for:
15 = lg (x * 1024)
=> 5 = lg (x)
2^5 = x
x = 32
Dvs. at for at forskellen mellem ZiN's (#205) bloatede DB og den normale skal være en faktor 32 for at holde vand.
#281
derr...
hvis nu funktionen var
f(x)=log2(x) − 100⋅ log2(log2(x)) + 500
så er f(1024)=177,80719
og f(32*1024)=124,31094
og f(x)=O(lg(x)) i øvrigt. Du glemmer at O-notationen skjuler konstanter, og det skal man ikke se bort fra i den virkelige verden.
Anyway, min pointe er at du ikke kan regne dig frem til sådan nogle tal ud fra O-notationen. Fy!
derr...
hvis nu funktionen var
f(x)=log2(x) − 100⋅ log2(log2(x)) + 500
så er f(1024)=177,80719
og f(32*1024)=124,31094
og f(x)=O(lg(x)) i øvrigt. Du glemmer at O-notationen skjuler konstanter, og det skal man ikke se bort fra i den virkelige verden.
Anyway, min pointe er at du ikke kan regne dig frem til sådan nogle tal ud fra O-notationen. Fy!
Jeg glemmer bestemt ikke konstanterne, men prøvede at illustrere dels hvad O notation betyder, og dels hvordan tidskompleksiteten ved binær søgning opfører sig.
Beklager hvis nogle troede at mine tidsenheder var noget der kunne oversættes direkte til virkeligheden.
Din formel beskriver til gengæld meget godt hvorfor log(n) er så pisse sej til store mængder data:
Først når der er mere end 2^500 keys i databasen, vil en søgning tage dobbelt så lang tid, som med kun een key i databasen. Dvs. først når man har en key for (hvert atom i universet)^6. (antaget vi har 10^80 atomer i universet)
Med andre ord, det sker aldrig.
Beklager hvis nogle troede at mine tidsenheder var noget der kunne oversættes direkte til virkeligheden.
Din formel beskriver til gengæld meget godt hvorfor log(n) er så pisse sej til store mængder data:
Først når der er mere end 2^500 keys i databasen, vil en søgning tage dobbelt så lang tid, som med kun een key i databasen. Dvs. først når man har en key for (hvert atom i universet)^6. (antaget vi har 10^80 atomer i universet)
Med andre ord, det sker aldrig.
Benjamin Krogh (281) skrev:Vi har nu at data-sættet skal være en faktor 1024 større for at et opslag tager dobbelt så lang tid.
Nej.
Data sættet skal kvadreres i størrelse for at et opslag tager dobbelt så lang tid.
Og det er lige netop for 1024 så 1024, men det er andet for andre værdier.
Benjamin Krogh (281) skrev:Dvs. at for at forskellen mellem ZiN's (#205) bloatede DB og den normale skal være en faktor 32 for at holde vand.
Kun ved 1024 entries.
@ O-notation
Man kan vel sige at det siger noget om hvad der tager længst tid med et (nær) uendeligt input. Ish...
Man kan vel sige at det siger noget om hvad der tager længst tid med et (nær) uendeligt input. Ish...
Arne: Jeg er helt enig i din præcisering af #281, men du mister desværre selv overblikket senere.
Du missede at jeg sætter ind i onetreehell's formel:
f(x)=log2(x) − 100 ⋅ log2(log2(x)) + 500
Vi kan, simplificere ved se bort fra delen med -100 * bla, da det kun hjælper mit argument.
Vi har da:
f(1)=log2(2^1) + 500 = 501
og f(500)=log2(2^500) + 500 = 1000
1000 / 501 ~= 2
2^500 tager 500 gange så lang tid som 2.
Du missede at jeg sætter ind i onetreehell's formel:
f(x)=log2(x) − 100 ⋅ log2(log2(x)) + 500
Vi kan, simplificere ved se bort fra delen med -100 * bla, da det kun hjælper mit argument.
Vi har da:
f(1)=log2(2^1) + 500 = 501
og f(500)=log2(2^500) + 500 = 1000
1000 / 501 ~= 2
#288
Jeg har lige prøvet f(2) og f(2⁵⁰⁰), og det giver hhv. 501 og 103,42...
Det er bestemt ikke til din fordel at fjerne -100*log2(x), da det så vil gælde at f(2)<f(2⁵⁰⁰)...
Prøv at hive en lommeregner frem og test min funktion... also, lrn2math
EDIT:
f(2)=501 > f(2⁵⁰⁰)=103,42...
Jeg har lige prøvet f(2) og f(2⁵⁰⁰), og det giver hhv. 501 og 103,42...
Det er bestemt ikke til din fordel at fjerne -100*log2(x), da det så vil gælde at f(2)<f(2⁵⁰⁰)...
Prøv at hive en lommeregner frem og test min funktion... also, lrn2math
EDIT:
f(2)=501 > f(2⁵⁰⁰)=103,42...
#289 tsk tsk. ;)
Måske burde jeg lrn2math. Jeg har tilgengæld lært ikke at hovere da jeg ved at jeg er fallible.
Du misser til gengæld fuldstændigt hvorfor det er absolut ligegyldigt med det midterste led.
Jeg skulle bevise at i eksemplet er f(2^500) ikke 500 gange større end f(2^1), men maksimalt dobbelt så stor.
Jvf. det du siger nu har vi, meget belejligt bør jeg indskyde, at 103/501 ikke er lig 500 og < 2. Mit argument holder derfor stadig vand. Det holder selvfølgelig da simplifikationen kun gør det sværere for mig.
Måske burde jeg lrn2math. Jeg har tilgengæld lært ikke at hovere da jeg ved at jeg er fallible.
onetreehell (289) skrev:Jeg har lige prøvet f(2) og f(2⁵⁰⁰), og det giver hhv. 501 og 103,42...
Du misser til gengæld fuldstændigt hvorfor det er absolut ligegyldigt med det midterste led.
Jeg skulle bevise at i eksemplet er f(2^500) ikke 500 gange større end f(2^1), men maksimalt dobbelt så stor.
Jvf. det du siger nu har vi, meget belejligt bør jeg indskyde, at 103/501 ikke er lig 500 og < 2. Mit argument holder derfor stadig vand. Det holder selvfølgelig da simplifikationen kun gør det sværere for mig.
#290
Har du prøvet log2(2)? og har du prøvet log2(2⁵⁰⁰)?
det første er selvfølgelig 1. Det andet er 500. Altså det er 500 gange større.
jeg ved ikke hvad du er ude på.... Du er da absolut clueless.
Har du prøvet log2(2)? og har du prøvet log2(2⁵⁰⁰)?
det første er selvfølgelig 1. Det andet er 500. Altså det er 500 gange større.
jeg ved ikke hvad du er ude på.... Du er da absolut clueless.
En gang til for prins Knud ;)
Arne postulerer i #285 at (f(n) | n = 2^500) er 500 gange større end (f(n) | n = 2). Dette er korrekt hvis man kigger på formlen i O(n) notation. Jeg prøver så at gøre opmærksom på at jeg i mit eksempel er gået bort fra denne notation og bruger din formel, nemlig f(x).
Samtidigt beviser jeg at f(2^500) ikke er 500 gange større end f(2^1).
Jeg postulerer samtidigt at man kan se bort fra midterste led, når man skal bevise at det ikke gælder at f(2) * 500 = f(2^500).
Du mener så, i #289 at jeg ikke kan se bort fra det midterste led. På trods af at dit eksempel faktisk understøtter mig i at se bort fra det.
I #291 forvirrer mig lidt. Hvorfor du går fra at snakke fra f(x) til kun at nævne log2(x) er mig ikke helt klart, i forhold til dine tidligere indlæg.
Arne postulerer i #285 at (f(n) | n = 2^500) er 500 gange større end (f(n) | n = 2). Dette er korrekt hvis man kigger på formlen i O(n) notation. Jeg prøver så at gøre opmærksom på at jeg i mit eksempel er gået bort fra denne notation og bruger din formel, nemlig f(x).
Samtidigt beviser jeg at f(2^500) ikke er 500 gange større end f(2^1).
Jeg postulerer samtidigt at man kan se bort fra midterste led, når man skal bevise at det ikke gælder at f(2) * 500 = f(2^500).
Du mener så, i #289 at jeg ikke kan se bort fra det midterste led. På trods af at dit eksempel faktisk understøtter mig i at se bort fra det.
I #291 forvirrer mig lidt. Hvorfor du går fra at snakke fra f(x) til kun at nævne log2(x) er mig ikke helt klart, i forhold til dine tidligere indlæg.
I O-notation så er f(2^500)=f(2)=O(1)... Min pointe er at man ikke kun skal kigge på O-notationen når man vil finde ud af den faktiske køretid i den virkelige verden. Der er konstanter og andre (mindre, set asymptotisk) led man skal have med for at få et nogenlunde korrekt resultat...
Min kritik går på at du prøver at bruge O-notationen til at udlede faktiske køretider, hvilket er helt forkert.
Jeg bliver også forvirret fordi du siger så meget mere eller mindre vrøvl...
Min kritik går på at du prøver at bruge O-notationen til at udlede faktiske køretider, hvilket er helt forkert.
Jeg bliver også forvirret fordi du siger så meget mere eller mindre vrøvl...
Som jeg tager skridtet videre og viser hvorfor lg(n) er nice. Vha. dit eksempel.onetreehell (293) skrev:I O-notation så er f(2^500)=f(2)=O(1)... Min pointe er at man ikke kun skal kigge på O-notationen når man vil finde ud af den faktiske køretid i den virkelige verden. Der er konstanter og andre (mindre, set asymptotisk) led man skal have med for at få et nogenlunde korrekt resultat...
At vise reelle køretider ud fra O notation er absurd, umuligt og dumt. Som jeg prøver at sige, er det kun for at illustrere hvad O dækker over, nemlig tidskompleksiteten.
Jeg er i tvivl om hvorvidt du i starten af #293 mener at jeg har taget O(2^500). Jeg vil i så fald gerne præcisere hvad jeg mener i #292, da jeg siger "kigger på formlen i O notation". Da mener jeg at hvis man tager lg(2^500) så vil det være 500 gange større end lg(2).
Med "kigger på formlen i O notation" mener jeg dermed, formlen: "lg(x)".
Jeg tror dette billede forklarer store O-notation bedre. Det der med at regne på konkrete tal skal man passe på med. Man kan hurtigt sige noget der er forkert.
Den formelle definition (de første 4 linjer bare) på wikipedia er også ret nem at forstå, men billedet ovenfor er nok bedre.
Den formelle definition (de første 4 linjer bare) på wikipedia er også ret nem at forstå, men billedet ovenfor er nok bedre.
Jeg vil lige tilføje at man kan se de forskellige symbolers betydning på wikipedia (samme link som i min forrige post) under "Family of Bachmann–Landau notations". Big O er jo ikke det eneste.
Benjamin Krogh (288) skrev:men du mister desværre selv overblikket senere.
Benjamin Krogh (288) skrev:Du missede at jeg sætter ind i onetreehell's formel:
Du skrev:
Benjamin Krogh (283) skrev:
Din formel beskriver til gengæld meget godt hvorfor log(n) er så pisse sej til store mængder data:
Først når der er mere end 2^500 keys i databasen, vil en søgning tage dobbelt så lang tid, som med kun een key i databasen.
Nej. log(n) giver ikke den effekt. log(n) giver en faktor 500 forøgelse fra 2 til 2^500 (og uendelig fra 1 til 2^500).
Det er korrekt at hvis du sætter ind i hans formel så giver det en faktor 2.
Men det er ikke en egenskab ved log(n).
Hvis du kigger på en funktion:
f(x) = a + b * g(x)
så vil du får vilkårlige k, x1 og x2 kunne bestemme a og b hvor:
f(x2) / f(x1) = k
uanset om g er log eller en anden funktion.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Tagwall
Gå til bund