sprintf vs. selber parsen, performance?

OP #1192751
Hi
Ich schreibe gerade an einem HTTP server für das Nei-IO board basierend 
auf dem "uWebSrv von simon k" und überlege gerade och ich für das 
verarbeiten der html templates ein sprintf verwenden sollte, oder lieber 
die string selber parsen,
ist da sprintf viel resourcen hungriger?

PS:;
sowas ist sicher auch subobtimal:
  strcpy(pBuffer,g_HtmlComboBegin);
  pBuffer+=strlen(pBuffer);
da wäre eine eigene copy funktion die den pointer gleich mit schiftet 
wohl auch deutlich performanter, oder?
sowas wie
1
int stradd(char* target, const char* source)
2
{
3
  int Length = 0;
4
  while(source[Length] != 0)
5
  {
6
    target[Length] = source[Length];
7
    Length++;
8
  }
9
  target+=Length;
10
  target[0] = 0;
11
  return Length;
12
}
#1192754
Da ich printf meist sowieso drin habe, verwende ich dann auch sprintf in 
solchen Fällen. Allerdings nicht für's komplette Template, weil sonst 
die Grösse des Zielpuffers eine hässliche Rolle spielen kann.

Also verwende ich eigene Templates mit einem einfachen Parser, der 
wenn's passt selber auch sprintf verwendet.

Wenn dir das Tempo eines Webservers Sorgen macht, dann bist du bei einem 
8bitter mit zuwenig Speicher für ein wirklich sauberes TCP-Protokoll (*) 
sowieso falsch. Da ist sprintf nicht das Problem.

*: Beispiel: Wenn der Sendepuffer der Wiznet TCP/IP-Controller zuwenig 
Speicher für 2 Frames hat, dann sendet das Teil jeden Frame zweimal 
über's Netz um die Performance zu verbessern(!). Sonst wird's aufgrund 
von Timeouts nämlich viel langsamer. Soviel zum Thema Performance.
#1192762
Wenn du schon solche String-Funktionen baust, dann bau die 
Buffer-Overflows nicht gleich mit ein. Also bau dir welche, die den 
fälligen Range-Check gleich mit enthalten.

Denk dran, dass im Netzpuffer vielleicht nicht genug Platz für den 
kompletten Ersatzstring ist. Wenn du dann mitten in einem solchen String 
neu aufsetzen musst wird's krass. Lieber vorher kontrollieren und ggf 
den alten Frame kürzer raussenden damit die Ersetzung garantiert in 
einem Stück passt.
#1192775
Klar, aber besser wär's du machst ebendies mitsamt Überlauftest in der 
Funktion. Entweder mit globalen Variablen weil es sowieso nur einen 
Puffer gibt, oder ein Pufferdescriptor als Parameter für die Funktion. 
Erspart dir die Notwendigkeit, das überall in den Aufrufen 
rumzuschleppen.
#1192992
Trax Xavier wrote:
> die usage ist so gedacht: pBuffer+=stradd(pBuffer,g_CfgHtmlHeader);


nicht besonders gut gedacht.
Du machst viel zu viele unnötige Operationen


Usage
1
    pBuffer = stradd( pBuffer, g_CfgHtmlHeader );

wobei stradd so definiert ist
1
char* stradd( char* Target, const char* Source )
2
{
3
  while( *source )
4
    *target++ = *source++;
5
  *target = '\0';
6

7
  return target;
8
}

Wenn du schon optimierst, dann machs richtig :-)

Das noch fehlende Argument für die target Länge musst du noch einbauen

Antwort schreiben

Eine eigene Frage? Dieser Thread ist über 17 Jahre alt. Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.

Neuen Thread starten

Eine Lösung, Ergänzung oder Rückmeldung zu diesem Thread? Dann antworte hier.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.