langsames cout; performance test und programmabruch...

LordJaxom

Zu der Ausgabegeschwindigkeit: Die hängt natürlich auch von der verwendeten Konsole ab. Die muss ja auch zeichnen, scrollen usw. Wenn das Programm über ssh o.ä. läuft, muss der Text noch übers Netz.

Teste die Laufzeit doch mal mit vollständiger Ausgabe, die Du aber a) in eine Datei und b) nach /dev/null umleitest...

ich habe erstmal die funktion:

string ret_str(int *array, size_t ln)
{
	char *cstring = new char[ln];

	for(int i = ln; i > 0; i--)
		cstring[ln-i] = ret_char(array[i-1]);
	string str = cstring;
	delete [] cstring;

	return str;
}

so umgeändert dass das speicherleck geschlossen ist. das prob ist nur dass nun ziemlich oft der cstring zu einem string umkopiert wird nur um diesen zurückzuliefern...

wenn ich das ganze einfach so gestalte

char *ret_str(int *array, size_t ln)
{
	char cstring[ln];

	for(int i = ln; i > 0; i--)
		cstring[ln-i] = ret_char(array[i-1]);

	return cstring
}

dann bekomme ich einen buchstabensalat:
statt:
bsp:

vergleiche: aafjbs mit string: hausba
vergleiche: aafjbt mit string: hausba
vergleiche: aafjbu mit string: hausba

sieht dass dann so aus:

vergleiche: aaab+% mit string: hausba
...
vergleiche: aafj*& mit string: hausba

hat sich erledigt; ich habe die absolut schnellste lösung ohne umkopieren gefunden!

string ret_str_quick(int *array, size_t ln)
{
string cstring;

for(int i = ln; i > 0; i--)
cstring += ret_char(array[i-1]);

return cstring;
}

thx für die hilfe!

du gibst ne adresse auf ein lokales array zurück (cstring), das kann nicht funktionieren. den speicher mit new zu allozieren ist schon richtig, du musst nur dafür sorgen, dass er irgendwann auch wieder freigegeben wird.

andererseits frag ich mich, warum du überhaupt nen cstring/string zurückgeben willst. hau doch den vergleich (strcmp) gleich mit in die funktion und returniere nur nen bool.

ok, ich habe mich etwas geirrt... das ganze mit den strings ist das mit abstand langsamste.

ich habe jetzt die funktion in die große schleife gepackt, mit new allokiert und schön deleted. jetzt muss ich nur die konsolenausgabe beschleunigen, denn die begrenzt das ganze auf ca 1 100 000 operationen, dabei wären ca 24 000 000 pro zeiteinheit möglich!! das ist nicht übel.

lolz

dgrat schrieb:

ok, ich habe mich etwas geirrt... das ganze mit den strings ist das mit abstand langsamste.

ich habe jetzt die funktion in die große schleife gepackt, mit new allokiert und schön deleted. jetzt muss ich nur die konsolenausgabe beschleunigen, denn die begrenzt das ganze auf ca 1 100 000 operationen, dabei wären ca 24 000 000 pro zeiteinheit möglich!! das ist nicht übel.

Das ist auch nicht verwunderlich, da die Ausgabe auf die Konsole sehr viel aufwändiger ist als deine einfache und sehr kurze Berechnung.

mikey

Mal in die Runde eingeschmissen: Mit welchem Tool kann ich herausfinden, ob und wo mein Programm Speicherleaks produziert? Mit dem Debugger (insb. ASM-Code) kenne ich mich nicht so gut aus.

The-Kenny

Unter Linux gibt es dafür valgrind

mikey

Ich meine für Windoze...

Hallo mikey,

falls mein Programm einfach abstürzt, verwende ich GDB,
zum Checken auf Memory-Leaks nehm ich MMGR.
Im Prinzip sind das Makro-Definitionen, die Funktionen aufrufen, die
Speicheranforderungen loggen. Kostet natürlich Performance und muss in jeder
Datei inkludiert werden. Ich includier immer ne Config-Datei, die mir
das nur includiert, wenn das Makro MMBR_DEBUG gesetzt ist.
So kann man das immer zwischendurch mal zum testen reinmachen.
Allerdings gibt es (sehr) wenige Ausnahmen (statische Objekte - unter
bestimmten Bedingungen - frag mich nicht, wann genau), wo es nicht funct.

EDIT: Naja nen Link wäre auch praktisch
http://www.koders.com/cpp/fidF4248EED693AB98956E4AF0D594164BCCAB31406.aspx
http://www.koders.com/c/fidBAB9E56219A304846FAA7A14102FD65103F1CB3F.aspx

Gruß,
CSpille