Jeg vil mene det er en rimelig måde at løse problemet på (under antagelse af: - at der ikke ske nogen fejl i sprintf - det ikke er bundet til en bestemt cpu arkitektur - int altid er 32 bit (11-tal skal ændres hvis ikke) - C99 kan omgåes ved en new, husk fejl check. - programmet kun kaldes få gange med små data set. - at ptr += sprintf(ptr, "%d", a[i]); ptr += sprintf(ptr, "%s", ","); udskiftes med ptr += sprintf(ptr, "%d,", a[i]); sparer et funktions kald
Hvis programmet her var en funktion kunne man køre en profiler på det og se om her bruges for meget tid i den.
Hvis det var tilfældet kan man gå videre og kikke på indholdet af funktionen. Se på sprintf som er en generel funktion til formatering og lave en egen version af den som er specialliceret til int. Jeg ville estimere at man kunne speede den op med en faktor 2 ved at gå fra generel til specialiseret.
En yderligere specialisering ved at gå fra kald til inline spare yderligere noget stack administration (push og pop af adresser, push af argumenter, pop af retur værdi) og med det korte kald af funktionen bliver det måske en faktor 1,5 til 2.
For løkkens hastighed er begrændset af at næste iteration er afhængig af den tidligere gennem opdateringen af ptr, dette skjules måske af kald til sprintf, hukommelses tilgang og cpu arkitektur.
Ved rigtig store data set kan må så splitte det op mellem 2 eller flere cpu'er, det kræver dog noget mere arbejde og er ikke direkte understøttet af C. Data settet splittes i X lige store dele og køre det på X cpu, de færdige char arrays lægges derefter sammen.
Ved rigtig tids eller plads kritiske funktioner kan man også overveje: - Er dette den rigtige måde at løse problemet på. - Hånd optimeret assembler kode. - Hvad er omkostningerne ved at lave bedre kode i forhold til at købe større computer.
Også målet for koden har indflydelse på om det er godt nok: - Til windows programmer er den vigtigste parameter at det går hurtigt at skrive, tid og plads forbrug er ligegyldige kunden kan bare købe en større computer. Features er vigtigere end hastighed, plads og korrekthed. - Til forbruger elektronik er det din omkostning at sætte større cpu og mere ram i, så her tænkes meget mere på plads, tid og korrekthed, da det koster at lave fejl. - Til kritiske applikationer tænkes først og fremmest på indbygget korrekthed, funktionen skal også være færdig på en forud defineret tid, plads er vigtig fordi plads er også tid. - Til videnskabelige/visse økonomiske/databaser tænkes meget på korrekthed og hastighed,en del på plads hvor plads helst skal begrændses da plads er tid. - Til spil tænkes først på hastighed, nogenlunde korrekthed, og plads er noget man som regel bare har ellers må brugeren opgraderer.
Tak for dit svar segmose! Denne funktion bliver brugt i noget embedded system, de arrays som skal konverteres til en streng, er heldigvis ikke ret store, så denne løsning er udmærket, ligebortset fra at jeg laver:
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.