Forum: Mikrocontroller und Digitale Elektronik sprintf vs. selber parsen, performance?


von Trax X. (trax)


Lesenswert?

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
}

von (prx) A. K. (prx)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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.

von Sven P. (Gast)


Lesenswert?

Dein stradd bringts nicht, weil 'target += Length' mit einer lokalen 
Kopie arbeitet.
Guck mal:
http://linux.about.com/library/cmd/blcmdl3_stpcpy.htm

von Trax X. (trax)


Lesenswert?

die usage ist so gedacht: pBuffer+=stradd(pBuffer,g_CfgHtmlHeader);

von (prx) A. K. (prx)


Lesenswert?

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.

von Sven P. (Gast)


Lesenswert?

Welchen Sinn hat dann 'target+=Length'?
Und immernoch: http://linux.about.com/library/cmd/blcmdl3_stpcpy.htm

von Trax X. (trax)


Lesenswert?

jo das kan ich mir sparen und darunter target[Length] = 0 anstadt 
target[0] = 0 machen
stpcpy ist bei meinem WinAVR nicht definiert in string.h
aber strlcpy ist evl das richtige

hängt

von Karl H. (kbuchegg)


Lesenswert?

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

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.