Dateien einlesen und vergleichen

PAD

Habe jetzt noch einmal die Laufzeiten verglichen mit MS Visual C++ 6.0 professional, mit interessanten
Ergebnissen.

Einmal in der Debugversion

Anzahl Durchlaeufe: 67108864 0x4000000
Begin test1 dummi (Overhead) End test1: 7.857198
Begin test2 substr alt PAD End test2: 48.689702
Begin test3 substr neu AJ End test3: 26.469494
Begin test4 entfWSC End test4: 21.819640
Begin test5 StrRmLe End test5: 56.789122
Test1 Ges: 7.857 Kor: 0.000 s, pro Run: 0.000 us
Test2 Ges:48.690 Kor:40.833 s, pro Run: 0.608 us
Test3 Ges:26.469 Kor:18.612 s, pro Run: 0.277 us
Test4 Ges:21.820 Kor:13.962 s, pro Run: 0.208 us
Test5 Ges:56.789 Kor:48.932 s, pro Run: 0.729 us

Einmal in der Releasversion Speed Optimiert

Anzahl Durchlaeufe: 67108864 0x4000000
Begin test1 dummi (Overhead) End test1: 4.062547
Begin test2 substr alt PAD End test2: 16.711492
Begin test3 substr neu AJ End test3: 33.469272
Begin test4 entfWSC End test4: 29.972967
Begin test5 StrRmLe End test5: 37.763907
Test1 Ges: 4.063 Kor: 0.000 s, pro Run: 0.000 us
Test2 Ges:16.711 Kor:12.649 s, pro Run: 0.188 us
Test3 Ges:33.469 Kor:29.407 s, pro Run: 0.438 us
Test4 Ges:29.973 Kor:25.910 s, pro Run: 0.386 us
Test5 Ges:37.764 Kor:33.701 s, pro Run: 0.502 us

AJ

@PAD
Also wenn es dir um Schnelligkeit geht, dann hätt ich noch ne schnellere Variante für deine Teilerfunktion:

void teiler(char **quelle, char **teil, char suche)
{
   char *pos;

   for(pos = *quelle; *pos && *pos != suche; ++pos);

   if(*pos)
   {
      *pos++ = 0;
      *teil = *quelle;
      *quelle = pos;
   }
}

Allerdings musst du dann beim Aufruf mit variablen Zeigern arbeiten:

...
char text[20] = "Text=Wert";
char *name, *wert;

wert = text;
teiler(&wert, &name, '=');

printf("Name: %s\nWert: %s\n", name, wert);

Warum müssen die Parameter eigentlich in dieser unvorteilhaften Verteilung sein??

PS: Die Schleife oben kann man auch durch strchr() ersetzen: pos = strchr(*quelle, suche);

Also diese Geschwindigkeitsergebnisse finde ich sehr seltsam. Besonders, weil im Debugmodus meine Funktionen schneller sind.

PAD

Weil wenn ich substr, eine Funktion die bei uns in einer Tool-Bibliothek seit zig Jahren verankert ist,
durch eine moderne Variante ersetze, diese Form Fit Funktion kompatibel sein muss.

input: " test1,360.0,a:b20:c30,t:20,450 "

dies sich leicht durch folgende Sequenz zerlegen läst, es ist übersichtlich den Rest input stehen zu haben

substr(input,testname,',');
substr(input,position,',');
substr(input,p1,':');
substr(input,p2,':');
substr(input,p3,',');
substr(input,dummi,':');
substr(input,Temperatur,','); // in Input steht jetzt noch 450

Hier 2 Beispiele aus der realen Welt
$HEHDT,338.0,T*26$ GPGGA,161330.00,5955.10,N:02452.48,E:2,00,0.0,0.0,M,0.0,M,0.0,0000*77

Die sonst nötige Abfolge ist deutlich unübersichtlicher
teil(input,rest,',');
strcpy(testname,input);
teil(rest,input,',');
strcpy(position,rest);
teil(input,rest,':');
strcpy(p1,rest);
....

Die Funktion Teiler sieht sehr interessant aus

Debug
Begin test6 teiler End test6: 22.198350
Test6 Ges:22.198 Kor:13.926 s, pro Run: 0.208 us
Release
Begin test6 teiler End test6: 10.375988
Test6 Ges:10.376 Kor: 6.320 s, pro Run: 0.094 us

Bleibt nur eine Frage wie vermeide ich die beiden strcpy´s // Form Fit Funktion

double test6(void)
{	int i;
	char Peter[129];
	char Peter1[129];
	char *name, *wert; 
    APPLTraceB(APPLV1,"test6 teiler")
	for (i=0;i<NUM;i++)
	{
	strcpy(Peter,"			  ist ein Test,hier der zweite Teil");
	wert=Peter;
	teiler(&wert,&name,',');
/**/    strcpy(Peter1,name);
/**/    strcpy(Peter,wert);
	}
  APPLTraceETa(APPLV1,"test6")
}

AJ

Auf die Art kannst du das strcpy() schlecht vermeiden.

Ich hab auch mal was mit dem NMEA-Protokoll vom GPS-Empfänger machen dürfen. Ich bin das damals, glaub ich, mit strchr() durchgegangen, hab die Trenner immer mit 0 überschrieben und die einzelnen Inhalte in eine Struktur gesteckt (als Zahlen hald ;)).

PAD

Das NMEA Protokoll ist nur ein Beispiel von vielen, in denen wir ASCII-Dateien "interpretieren" um Daten
Auswertung zu betreiben.
Aber Interessant, das du es auch kennst

AJ

Ich musste die Daten des GPS-Empfängers auswerten und auf einem Handheld-PC ausgeben (zum Glück nur Text). Durch die Programmierung des Handhelds hab ich einige Erfahrung mit seriellen Schnittstellen und anschließbaren Geräten gesammelt. Ich musste dann auch mal einen GPS-Simulator schreiben. Der hatte einen Start und Endpunkt und musste dann von dem einen Punkt zum anderen fahren. Sogar die Geschwindigkeit musste sich regulieren lassen. War ganz interesant.

PAD

Da ich in der Testgeräteentwicklung einer Navigationsfirma arbeite, habe des ständig mit solchen und
vielen ähnlichen Problemen zu tun.

Es sind Prüfprogramme und Simulatoren für unsere Produkte zu entwickeln, damit man bei diesen sowohl die Designtests als auch die Endkontrolle sinnvoll durchführen kann

Windalf

PS: falls einer für StrRmLe eine bessere Implementierung weis, ich bin neugierig?

ich würds so machen

void StrRmLe(char *s){
int x=strlen(s);
for(char *p=s;isspace(*p);++p);
if(p-s)memmove(s,p,x+1-(p-s));
}

AJ

@Windalf
Hast du den Code auch getestet??

Windalf

@AJ
äh nein, wie immer nicht
direkt so ins forum gehackt... hast du schon einen fehler gefunden?

aber was hälst du von der variante... nicht besonders schön aber schön wenig zeichen...

void remove_spaces(char*s){for(;*s==32;)memmove(s,s+1,strlen(s));}

AJ

Schlecht, da du 32 anstatt ' ' verwendest (mal davon abgesehen, dass das nicht das einzigste WhitSpaceChar ist => Themaverfehlung) und außerdem der Code extram langsam ist, weil du bei jedem Schleifendurchlauf, den kompletten übrigen String durchläufst (strlen()) und dann auch noch den kompletten übrigen String kopierst (also nochmal ein kompletter durchlauf des Strings).

Die erste Variante, die gepostest hast, war besser. Wobei man du da auch einen unnötigen Durchlauf produzierst, indem du am Anfang strlen() verwendest und dann noch memmove(). Darum hab ich auch bei meiner Variante das strcpy verwendet (nur einmal ein Durchlauf; geh ich davon aus). Außerdem bin ich mir nicht sicher, ob isspace() nicht auch das Stringendezeichen als WhiteSpaceChar erkennt. Wenn ja, dann können bei deiner Variante Fehler auftreten. Aja und was den Fehler angeht, den ich gefunden habe: Wie lange sind lokale Variablen gültig?? (Tipp: Schau dir deine Schleife an)

Windalf

Schlecht, da du 32 anstatt ' ' verwendest

klar das spart mir ja ein ascii-zeichen...

und außerdem der Code extram langsam ist, weil du bei jedem Schleifendurchlauf, den kompletten übrigen String durchläufst (strlen())

ich hab ja auch gesagt nicht besonders schön aber schön wenig zeichen...

Aja und was den Fehler angeht, den ich gefunden habe: Wie lange sind lokale Variablen gültig?? (Tipp: Schau dir deine Schleife an)

stimmt zu diesem teil verleitet mich mein visual c des öfteren (und ich sollte mir das abgewöhnen) weil er dort im schleifenrumpf deklarierte variablen fälschlicher weise als im dazugehörgen block gültige variable deklariert... jo ist ein fehler wenn mans nicht mit nem vc-compiliert und damit nicht ansi-standard...muss ich dir leider (aber auch nur ausnahmsweise ) recht geben...

AJ

Was bringt es dir so wenig Zeichen wie möglich zu haben und dafür (zumindest) Lesbarkeit und Performance einzubüßen?? (der compilierte Code wird deswegen auch nicht weniger; vielleicht sogar das Gegenteil)

Ich hab das wenig schön übrigens auf die Formatierung bezogen (die ist nämlich auch nicht gerade schön)

Windalf

Ich hab das wenig schön übrigens auf die Formatierung bezogen (die ist nämlich auch nicht gerade schön)

Die alte Leier also

AJ

Windalf schrieb:

Ich hab das wenig schön übrigens auf die Formatierung bezogen (die ist nämlich auch nicht gerade schön)

Die alte Leier also

Im Chaos findet man sich hald schwerer zurecht

Windalf

Im Chaos findet man sich hald schwerer zurecht

Überall wo ich bin herrscht Chaos...leider kann ich nicht überall sein