Geschwindigkeit von Strings
-
KingOfTheBlueMouse schrieb:
ich würde mit
long anfang = GetTickCount(); // Was mit dem string tun long ende = GetTickCount(); cout << ende - anfang << endl;die zeit stopen und vergleichen
Naja, GetTickCount() arbeitet auf einigen Plattformen sogar mit 16ms Schritten, deswegen wäre wohl z.B. ein QueryPerformanceCounter angebrachter.
Ich kannte mal eine Seite wo Benchmarks von strings mit zuweisungen, etc. im Vergleich zu char* durchgeführt wurden auf ziemlich alten PC, so 286 und co. Das Fazit war, das die string-Klasse meistens besser war. Leider find ich die Seite nicht mehr

mfg.
-
Naja, GetTickCount() arbeitet auf einigen Plattformen sogar mit 16ms Schritten, deswegen wäre wohl z.B. ein QueryPerformanceCounter angebrachter.
und wieder was gelernt
-
KingOfTheBlueMouse schrieb:
ich würde mit
long anfang = GetTickCount(); // Was mit dem string tun long ende = GetTickCount(); cout << ende - anfang << endl;die zeit stopen und vergleichen
Danke, aber das mit der Zeit mach ich einfach mit Boost.Timer, so schnell wird das ganze schon nicht ablaufen. Es geht eher um das, was joomoo angesprochen hat. Kennt irgendjemand anderes solche Seiten? Gibts vielleicht etwas "praxisnahes"?
-
.filmor schrieb:
die zeit stopen und vergleichen
Danke, aber das mit der Zeit mach ich einfach mit Boost.Timer, so schnell wird das ganze schon nicht ablaufen. Es geht eher um das, was joomoo angesprochen hat. Kennt irgendjemand anderes solche Seiten? Gibts vielleicht etwas "praxisnahes"?[/quote]
Mich würde interessieren warum du das wissen möchtest? Generell oder erscheinen dir "C-Strings" performanter?
-
Ne, ich hab ne eigene Stringklasse geschrieben. Es geht vor allem darum, wie die Strings gespeichert werden. An diesem Punkt kann ich das noch auf Policies aufteilen, aber erstmal möchte ich testen, ob einfache STL-Container (vor allem vector und deque) es auch tun, bzw. vor allem wie schnell sie sind.
-
.filmor schrieb:
Ne, ich hab ne eigene Stringklasse geschrieben. Es geht vor allem darum, wie die Strings gespeichert werden. An diesem Punkt kann ich das noch auf Policies aufteilen, aber erstmal möchte ich testen, ob einfache STL-Container (vor allem vector und deque) es auch tun, bzw. vor allem wie schnell sie sind.
Was heißt wie die Strings gespeichert werden?
Meinst du den internen Zeiger auf den C-String der Klasse oder meinst du ein Array von Stringklassen?Was sind Policies?
-
Policies werden in "Modernes C++ Design" von Alexandrescu (und noch an verschiedenen anderen Stellen) beschrieben, s. Link. Sie sind sehr praktisch, wenn eine Klasse auf gleiche Weise mit verschiedenen Verfahren implementiert werden kann, hier die Speicherung der Strings. Ziel ist es, nicht mehr seperate Klassen für string und rope (also eine Klasse für sehr lange Strings zu haben, gehört zu den SGI STL-Erweiterungen ist aber auch bei der GNU c++stdlib dabei) zu haben, sondern das über eine Policy zu bestimmen.
Ein weiteres Ziel ist es, verschiedene Encodings zur Compile-Zeit zu unterstützen um UTF-8 in annehmbarer Geschwindigkeit mit einem Standard-ähnlichen String benutzen zu können, ohne das wirklich zu merken (deshalb ist das Encoding bei mir auch quasi eine Policy).Mit Daten meine ich wirklich die richtige Speicherung. Sie muss eigentlich nur Iteratoren unterstützen (echte Pointer sind also nicht direkt drin, nur über ein Struct).
template<typename Encoding, template<typename> class Storage> class string { public: typedef Storage<typename Encoding::base_type> storage_type; // ... private: storage_type _data; };
-
die frage, 'wie' schnell etwas ist, ist häufig schwer zu beantworten, das hängt einfach von zu vielen nebenbedingungen ab. interessant ist meistens aber nur, wie sich eine operation im vergleich zu anderen verhält - in diesem falle hat man bessere kontrolle darüber, dass in beiden fälle die selben bedingungen für die messung herrschen. jede der genannten bedingungen könnte also akzeptabel sein. eine weitere möglichkeit ist die benutzung des time stamp counters (und damit die höchstmögliche sinnvolle auflösung in takten), sofern man sich der einschränkungen bewusst ist. soferen es sich um ein ein-prozessor single-core (HT schadet nicht) system handelt, kann man das einsetzen. die hohe auflösung hat den vorteil, dass die gemessenen zeiten relativ kurz sein dürfen (im bereich weniger hundert takte), somit schränkt man den einfluss externen bremsen ein, zusätzlich kann man das gut mittels volkards minimum algorithmus optimieren.
#include <iostream> typedef unsigned long long u64; #ifdef __GNUC__ inline u64 rdtsc() { u64 result; asm( "rdtsc" : "=A" (result) ); return result; } #elif define _MSC_VER inline u64 rdtsc() { asm rdtsc; } #endif int main() { u64 minimum = ~0ull; for ( int i = 10000; i; --i ) { u64 t = rdtsc(); // mach was... t = rdtsc() - t; if ( t < minimum ) { minimum = t; i = 10000; } } std::cout << minimum; }
-
@filmor: du bist nicht der erste (und sicher auch nicht der letzte), der sich daran versucht. wegen der speichermethode schau dir auch mal Alexandrescus flex_string an.
-
Ist das in Loki?
/edit: Ist gut, habs mit Google gefunden ...