Det er umuligt at give et konkret svar på. Det kommer 100% an på hvordan den bliver implementeret.
Jeg kan prøve at give dig en ide om hvor mange recurser der skal bruges som minimum med en god implementation. Bemærk jeg bruger runde tal ved godt det ikke er 100% præsist.
Du har 10 millioner linjer tekst. Jeg vil vælge at antage at der er gennemsnitlig 250 tegn i en linje. Det giver i alt cirka 2.500.000.000 eller 2,5 mia tegn. Nu er vi så heldige at langt de fleste normale engelske tegn (a-z,0-9 osv) bruger 1 byte i ASCII som er standarten. Det giver os igen 2.5 mia bytes eller omkring 2,5 GB. Det vil sige at hvis vi bare smidder alt meneingsløst ind på ramne bruger vi rundt regnet 2,5 GB. Det behøver vi nu ikke men desto størrer del af dataen ligger op harddisken desto længere tid skal vi bruge på at flytte data fra haddisk til ram hvilket er et problem da man læser langsommere fra haddisken end fra ram. Hvis vi skal optimere i forhold til cpu skal vi altså have 2,5 GB ram til rådighed som minimum men du kan i pricippet bruge meget mindre så køre programmet bare langsommere. Det skal dog siges at hvis vi laver en dårlig implementation vil det dog kræve flere ram.
Hvor lang tid tager koden så at køre? Det kommer an på en masse ting så som CPU, styresystem mm. Det er dog realistisk at finde ud af hvor mange gange vi skal sammenligne 2 rækker og hvis vi ved hvor lang tid det tager så har vi et godt estimat. Den lette løsning ville være at sammenligne alle de forskellige rækker med hinanden og så fjerne dem der er ens. Worst case er der ingen der er ens og vi ender derfor med at lave 10.000.000^2 sammenligninger eller 100.000.000.000.000 eller 100.000 mia gange. Vi kan dog gøre det hurtigere. Hvis vi sortere dataen først så kan vi f.eks. nøjes med 10 mil sammenligninger. Sortering tager dog tid. Uden at gå for meget i detaljer vil jeg afsløre at det gøres i bedste fald med det vi i IT verdnen kalder worstcase køretid n*log(n) hvor n er antallet af data eller i dette tilfælde linjer. Det betyder at vi skal tage 10 mil * 2 tals logeritmen til 10 mil. 2 tals logeritmen til 10 mil er cirka 22 så omkring 220 mil + de 10 = 230. Her er mit gæt så dog at du skal lægger omkring 40 mb til ramforbruget hvis du gerne vil have linjerne ud i den samme rækkefølge foruden potetielt 220 mil ekstra oprationer. Hvor lang tid tager det så at sammenligne og flytte 2 linjer. Tja ikke særlig lang tid men det kræver at man forsøger sig frem for der er massere af ubekendte. Hvis vi nu antager at det tager cirka 0,00001 sek. (tror ikke det er helt urealistisk med 0,01 millisekund) så vil vi altså bruge op til 230 mil * 0,00001 s eller 2300 sekunder for at få alle linjerne ud i sorteret orden og 4500 sekunder for den oprindelige orden. Dette giver os et rundt estimat på hhv 38,333 min og 75 min. Mere hvis du mangler ram. Hvis du programmere godt og har flere kerner osv. kan du selvfølgelig få det her ekstra ned.
Hvad er konklusionen så? Jeg tror jeg ville kigge på serveren og se hvor mange ram der er. Hvis du har mere end 8 GB ram så ville jeg nok gå klart efter processerkraft ved mindre end du brunger serveren til andre hårdre ting. Hvis du har mindre end 4 GB ville jeg helt sikkert gå efter ram. Mellem de 2 ved jeg ikke helt hvad jeg ville vælge. Alternativt kan du jo teste din server. Jeg ville nok se hvor lang tid det tager i dag og hvor fyldte ramne bliver når jeg sætter den igang med nogle lidt mindre testopgaver. Her ville jeg nok starte med at give den f.eks. 10.000 linje og så 100.000 linjer, 1.000.000 mil linjer og så 10.000.000 linjer for at se hvad der sker. Du kan overvåge processor og ram forbrug på serveren i mellemtiden. Hvis rammene bliver fyldt op ville jeg skaffe flere af dem først.
Bliv gratis medlem
Opret bruger