Problem: argv und string
-
ne 60 MB/s platte kann grob 10 mio zahlen die sekunde aufnehmen.
auf ner 2 GHz box sind das dann 200 takte je zahl.platte und CPU halten sich da wohl noch die waage.
du hast deine festplatte mit gemessen.
wie waers, wenn du die performance nicht an hand von festplatten oder INC operationen misst?
probiers doch mal mit methodenaufrufen und rekursion.
-
gewi schrieb:
printf ist schneller als cout, da es keine Klassen verwendet....
Warum nimmst Du dann nicht printf() ?
Übrigens: Wenn Du std::string genauso verwendest wie CStrings (keine dynamische Längenveränderung), ist es auch nicht langsamer, sondern eher schneller (explizite Längenangabe auslesen ist schneller als jedesmal '\0' suchen).
Achja: Wenn Geschwindigkeit Dein einziges Kriterium ist, solltest Du wrklich zu ASM wechseln. Wenn Du dagegen irgendwann mal fertig werden willst mit programmieren (und Dein Programm ohne Fingerbruch debuggen/weiterentwicklen) willst, fährst Du mit C++ besser.
Was programmierst Du eigentlich, dass Performance für Dich so viel wichtiger ist als unser 24/7-Multitasking-Server (der mit super-Performance seit Jahren unter C++ läuft) ?
Gruß,
Simon2.
-
~wenns mir auf performance nicht ankommt, nehm ich persoenlich scriptsprachen.
da wird man wenigstens mal fertig.~
-
thordk schrieb:
lässt sich so pauschal auch nicht sagen. viele reinen c-methoden, gerade diejenigen, die direkt auf dem speicher arbeiten, sind rasend schnell. aber das sind dinge, um die man sich nen kopf machen kann, wenn man in der lage ist, robuste und effiziente programme zu designen. das ist ein langwieriger prozess, der jahre dauert. und erst wenn man diesen stand erreicht hat, dann lohnt es sich, mal auf "mikrooptimierungen" zu achten. aber bevor man soweit ist, sollte man lieber auf standards zurückgreifen, die das problem anständig lösen. wenn vielleicht auch ne halbe sekunde langsamer.
Viele reine C++-Methoden, die direkt auf dem Speicher arbeiten sind rasend schnell.
Die Schnelligkeit von C gegenüber C++ ist eine Legende. C ist häufig schneller als C++, weil da unsauberer programmiert wird. "strcpy" gegenüber "std::string" ist ein gutes Beispiel.
"strcpy" ist prinzipiell schneller als eine Zuweisung an einen "std::string", da es keine Pufferprüfung macht. Eine Zuweisung an einen "std::string" reserviert ausreichend Speicher bevor es den String kopiert. Das tut strcpy nicht. Will ich in C das nachprogrammieren, habe ich deutlich mehr Arbeit und bin dann genauso "langsam" wie C++.
Diese Mehrarbeit ist auch der Grund, warum C für Pufferüberläufe anfällig ist und C++ nicht. Es ist einfach aufwändig, korrekte C-Programme zu schreiben.
Ein paar weitere Vorschläge, wie Du Dein Programm schneller machen kannst (so rein provokativ): verzichte auf Fehlerprüfung - das kostet Zeit, die normalerweise unnötig ist. Verwende feste Puffer und hoffe, daß die ausreichend groß sind. Dann werden nicht so zeitraubende Speicherallokationen vorgenommen.
-
c.rackwitz schrieb:
~wenns mir auf performance nicht ankommt, nehm ich persoenlich scriptsprachen.
da wird man wenigstens mal fertig.~~
Na, vielleicht bei 80-PJ-Projekten auch nicht mehr.
(wobei ich nicht genau weiß, welche "Skriptsprachen" Dir vorschweben).
Außerdem ist das Feld zwischen "Performance ist alles" und "Interessiert niemanden wann das PG fertiggerechnet hat" ziemlich weit...Gruß,
Simon2.
~
-
was meinst du, warum ich gesagt hab, dass man sich über solche "optimierungen" erstmal keine gedanken machen soll, tntnet?
es gibt durchaus fälle, in denen es auf jedes fitzelchen performance ankommt, man in wohl definierten parametern arbeitet und genau aus diesem grund auf fehlerkontrolle, zugunsten von performance, verzichten kann.
überlicherweise sollte dies allerdings tunlichst vermieden werden.
-
thordk schrieb:
...
es gibt durchaus fälle, in denen es auf jedes fitzelchen performance ankommt,...Stimmt !
Aber ich behaupte mal, dass mindestens 95% der Fragesteller hier, die lieber selbst mit char[] rumhantieren, "weil strings ja so lame sind" und dann fragen, wieso sie Speicherüberläufe bekommen (oder wie man new[] korrekt verwendet),
NICHT an einem dieser Fälle arbeiten.Ich würde deswegen hier immer erstmal zu StdLib-Lösungen raten und erst am korrekt arbeitenden Programm anhand konkreter Performanceanalysen und -anforderungen Optimierungen vorschlagen. (was Du eben als "üblicherweise" bezeichnet hast)
Gruß,
Simon2.
-
Und genau in dem Fall, wo Kommandozeilenparameter ausgewertet werden, kann ich mir nicht vorstellen, daß es auf Performance ankommt. Es ist eher einer der Fälle, wo man gerade keinen Einfluß darauf hat, was denn so rein kommt.
-
tntnet schrieb:
Und genau in dem Fall, wo Kommandozeilenparameter ausgewertet werden, kann ich mir nicht vorstellen, daß es auf Performance ankommt. Es ist eher einer der Fälle, wo man gerade keinen Einfluß darauf hat, was denn so rein kommt.
Wieso sollte das Einlesen von Kommandozeilenparameter ein Indiz für "Performancerelevanz" sein ?
Ich schreibe NUR Konsolenprogramme und bei denen sind 99% performanceirrelevant ... und selbst beim verbleibenden 1% schreibe ich sie erstmal sicher und korrekt und teste erst abschließend auf Optimierungsnotwendigkeit (nicht jede Optimierungsmöglichkeit muss auch ergriffen werden).Ich würde gerade anders herum sagen: Gerade weil man nicht weiß, was alles ins Programm geschmissen wird, spielt Sicherheit eine zentrale Rolle ... und da kann man bzgl. Speicherüberlauf (z.B. durch lang/viele Parameter) mit std::string deutlich weniger falsch machen als mit CStrings.
Gruß,
Simon2.
-
@Simon2: ich glaube, Du hast mich falsch verstanden. Ich sagte doch, daß bei Kommandozeilenparameters es nicht auf Performance, sondern auf Sicherheit ankommt. Daher ist es gerade ein gutes Beispiel, wo man std::string verwenden sollte. Das starten eines Konsolenprogramms und füllen der Parameter dauert im vergleich zur Verwaltung von std::string signifikant länger. Daher ist eine Optimierung bei Kommandozeilenparametern sinnlos.
-
tntnet schrieb:
@Simon2: ich glaube, Du hast mich falsch verstanden. Ich sagte doch, daß bei Kommandozeilenparameters es nicht auf Performance, sondern auf Sicherheit ankommt. Daher ist es gerade ein gutes Beispiel, wo man std::string verwenden sollte. Das starten eines Konsolenprogramms und füllen der Parameter dauert im vergleich zur Verwaltung von std::string signifikant länger. Daher ist eine Optimierung bei Kommandozeilenparametern sinnlos.
Ahaaaaa !!!!
Wer lesen kann, ist schwer im Vorteil:Simon2 schrieb:
tntnet schrieb:
Und genau in dem Fall, wo Kommandozeilenparameter ausgewertet werden, kann ich mir nicht vorstellen, daß es auf Performance ankommt. Es ist eher einer der Fälle, wo man gerade keinen Einfluß darauf hat, was denn so rein kommt.
...
Sorry,
Simon2.