string vs char*

nein von c++
aber ich habe gehört das C ein wenig schneller ist, da C++ programmierer die etwas langsamere standardbibliothek benutzen und diese langsamer ist

Don06

if (!Duden.find("performiert"))
    throw bad_lexical("Could not find performiert.");

Duden.
Strings und Vectoren sind so schnell wie dynamische Arrays (zumindest bei mir, natürlich nicht im Debug-Build aber das ist uninteressant). Es gibt also keinen Grund sie nicht zu verwenden. Im Gegensatz zu statischen Arrays können sie allerdings bei der Allokation langsamer sein (was sie bei mir z.B sind). Allerdings verliert man durch die Benutzung von rohen Arrays ziemlich viel Sicherheit und Komfort. Man sollte also dann seine STL Strukturen ersetzen, wenn einem der Profiler gesagt hat, dass genau diese und nichts anderes der Flaschenhals in einem performance-kritischen Bereich sind. Sonst sehe ich da eher weniger Anwendungsgebiete.
Ach ja, statisch konstante Arrays missbrauche ich manchmal als Lookuptable, aber nur std::map sich als wirklich zu langsam erwiesen hat. Allerdings hoffe ich das das mit std::unordered_map aus C++0x dann auch zur Vergangenheit gehört.

Gruß
Don06

Krux

Die performance ist in 99% aller Fälle die Überlegung nicht wert. Machs wie Jasc es gesagt hat.

BorisDieKlinge

kannst ja mal testen;)

erstell mal ein statische Array und ein Vecotr

double dArray[100];

std::vector<double> dVector(100);

for(int i=0; i< 100000; ++i){
for(int k=0; k< 100; ++k)
  dArray[k]=k*2;
}

for(int i=0; i< 100000; ++i){
int k=0;
for(std::vector<double>::iterator it = dVector.begin(); it =! dVector.end(); ++it,++k)
  (*it)=k*2;
}

mies mal die zeiten...

Shade Of Mine

für statische arrays gibt es boost::array<>

Don06

BorisDieKlinge schrieb:

mies mal die zeiten...

Was willst du damit sagen? Beide Codes erzeugen in etwa dasselbe Assembly (im Release Build). Unterschiedliche Zeiten haben also wenn überhaupt andere Ursachen.

#include <vector>

void traverse_vector(std::vector<double>& vector);

void traverse_array(double (&array)[100]);

int main()
{
	std::vector<double> vector(100); 
	double array[100];

	traverse_vector(vector);
	traverse_array(array);
}

void traverse_vector(std::vector<double>& vector)
{
	int k = 0;
	for (std::vector<double>::iterator iter = vector.begin();
		 iter != vector.end(); ++iter, ++k)
		(*iter) = k * 2; 
}

void traverse_array(double (&array)[100])
{
	for(int k = 0; k != 100; ++k) 
		array[k] = k * 2; 
}

Assembly für traverse_vector (inline):

; 13   : 	traverse_vector(vector);

$LL18@main:
	fild	DWORD PTR tv292[esp+832]
	add	DWORD PTR tv292[esp+832], esi
	add	eax, 8
	fstp	QWORD PTR [eax-8]
	cmp	eax, ecx
	jne	SHORT $LL18@main
$LN16@main:

Assembly für traverse array(ebenfalls inline):

; 14   : 	traverse_array(array);

	xor	eax, eax
	mov	DWORD PTR tv304[esp+832], eax
	lea	ecx, DWORD PTR _array$[esp+832]
	npad	4
$LL47@main:
	fild	DWORD PTR tv304[esp+832]
	add	eax, esi
	add	ecx, 8
	mov	DWORD PTR tv304[esp+832], eax
	fstp	QWORD PTR [ecx-8]
	cmp	eax, 200				; 000000c8H
	jne	SHORT $LL47@main

Man beachte, dass traverse_array zuerst den "Müll" von traverse_vector aufrümen muss, aber das wäre umgekehrt genauso.

Ach ja, Compiler MSVC 2008. Höchste Optimierungsstufe.

Gruß
Don06

BorisDieKlinge

ich will damit sagen, das es performance technisch gesehen.. keine "relevanten" unterschiede gibt;)

http://www.duden.de/duden-suche/werke/fx/000/106/mies.106806.html
Hat nichts mit messen zu tun.

Er Russe und nix Deutsch egro nicht 100% Deutsch Rechtschreibung.

Hier im Forum wird schikaniert wo's nur geht hab ich schon erkannt.

Simon2

performance schrieb:

was ist perfomierter?
String oder char*
vector oder array was benutzt ihr?

Hmmm, also ich kenne "Perdormance" nur Laufzeitmessungen - und diese nur von Vorgängen und niemals von Objekten. Der Begriff "Performance" ist also nur verwendbar, wenn man etwas tut und ich würde sagen, solange nicht irgendwie definiert wird, was mit char*, string, vector, .... getan werden soll (und wie), ist schon die Fragestellung nicht sinnvoll.

Analog: "Ist Fahren violetter als Schwimmen ?"

Das klingt vllt. etwas abgehoben, soll aber auf ein Kernproblem hinweisen: Wer einen Vergleich trotzdem versucht, wird sich Ewigkeiten in "Äpfel&Birnen"-Problemen verheddern...

Gruß,

Simon2.

hustbaer

BorisDieKlinge schrieb:

ich will damit sagen, das es performance technisch gesehen.. keine "relevanten" unterschiede gibt;)

Es gibt je nachdem was man damit aufführt ganz dramatische Unterschiede.
Was nicht heissen soll dass man verfrüht optimieren sollte.

Oder würdest du es für sinnvoll und gut erachten eine Vektorklasse für nen 3D Spiel z.B. so zu implementieren:

template <class T, unsigned N> class Vector
{
public:
    Vector() : m_vec(N) {}
    // ...
private:
    std::vector<T> m_vec;
};

Und sag jetzt nicht das sei Realitätsfremd, denn das ist 1:1 einem realen Beispiel nachempfunden. Code der als production-ready abgegeben wurde. Bloss dass dort gleich die std::vector<float> rumgereicht wurden, ohne Wrapper-Klasse. By Value. An 100 Stellen. Und zugewiesen und verglichen und ... ich glaube man kann sich ein Bild machen.

EDIT:

solange nicht irgendwie definiert wird, was mit char*, string, vector, .... getan werden soll (und wie), ist schon die Fragestellung nicht sinnvoll (...)

ACK

Ist Fahren violetter als Schwimmen ?

Weiss nicht, aber nachts isses ganz sicher kälter als draussen

hustbaer schrieb:

BorisDieKlinge schrieb:

ich will damit sagen, das es performance technisch gesehen.. keine "relevanten" unterschiede gibt;)

Es gibt je nachdem was man damit aufführt ganz dramatische Unterschiede.
Was nicht heissen soll dass man verfrüht optimieren sollte.

Oder würdest du es für sinnvoll und gut erachten eine Vektorklasse für nen 3D Spiel z.B. so zu implementieren:
template <class T, unsigned N> class Vector
{
public:
    Vector() : m_vec(N) {}
    // ...
private:
    std::vector<T> m_vec;
};
Und sag jetzt nicht das sei Realitätsfremd, denn das ist 1:1 einem realen Beispiel nachempfunden. Code der als production-ready abgegeben wurde. Bloss dass dort gleich die std::vector<float> rumgereicht wurden, ohne Wrapper-Klasse. By Value. An 100 Stellen. Und zugewiesen und verglichen und ... ich glaube man kann sich ein Bild machen.

Falsche Parameterübergabe hat aber nichts mit dem eigetnlichen Performanceunterschied zwischen vector und array zu tun

aber is doch eh nur n troll thread...

hustbaer

666...... schrieb:

Falsche Parameterübergabe hat aber nichts mit dem eigetnlichen Performanceunterschied zwischen vector und array zu tun

Oh Mann du Doofnuss.
Dass die Teile by value rumgereicht wurden ist doch nur das Tüpfelchen auf dem i.
Als Returnwert z.B. MUSS hier kopiert werden, und einen std::vector<float> mit Grösse 3 zu kopieren kostet halt einfach zig mal mehr als schnell mal eben 3 floats rumzuschieben.

BorisDieKlinge

ACK, aber:

class Foo{
...
pulbic:
Foo(){..}
Foo(const Foo &scr){
.
.
.
}
.
.
};

Foo *pA= new Foo[10];
std::vector<Foo> pV(10);
.
.
.
.

geht es hier nich gleich lan das array oder den vector zu kopieren?

hustbaer schrieb:

666...... schrieb:

Falsche Parameterübergabe hat aber nichts mit dem eigetnlichen Performanceunterschied zwischen vector und array zu tun

Oh Mann du Doofnuss.
Dass die Teile by value rumgereicht wurden ist doch nur das Tüpfelchen auf dem i.
Als Returnwert z.B. MUSS hier kopiert werden, und einen std::vector<float> mit Grösse 3 zu kopieren kostet halt einfach zig mal mehr als schnell mal eben 3 floats rumzuschieben.

ach ja, dass hier die Leute immer dann meinen den anderen als dumm darstellen zu müssen, wenn sie es selber sind...

schau dir mal Google: named return value optimization an

Und wenn du da wirklich ein Performace Problem hast, weils dein Compiler nicht optimieren kann, dann kannst du das gleiche selber machen. Und somit sind wir wieder bei

Falsche Parameterübergabe hat aber nichts mit dem eigetnlichen Performanceunterschied zwischen vector und array zu tun

P.S: Auf das nächste dumme geflame werd ich nicht mehr antworten

Simon2

Wie immer: Die Anonymität des Internets verleitet anscheinend immer dazu, unfreundlicher, ruppiger, pampiger, ... zu schreiben - und gleichzeitig viel empfindlicher zu lesen. Schon interessant, dass Gelassenheit durch die Distanz und Unverbindlichkeit nicht zu- sondern abnimmt.....

Gruß,

Simon2.