Lohnt sich Call by Reference bei Simplen Containern (CString, std::string)?
-
Das ist jetzt wohl eher eine Frage an Compilerbauer. Was erzeugt mehr Overhead:
- das CString / std::string Objekt zu kopieren und mit einer lokalen kopie zu arbeiten
- oder diese Objekte per Call by Reference zu übergebenIst es beim letzteren nicht so, das der Prozessor immer (?) direkt auf die Speicheradressen mit dem Inhalt zugreifen muss? Und beim ersten Fall den Inhalt vieleicht in einem Register hält?

Oder hängt das nur wieder von der Benutzung ab.
-
Bei eigentlich allem (außer vielleicht elementare Typen wie int oder double) lohnt sich die Referenz gegenüber einer Kopie.
(vor allem mußt du bedenken, daß bei einer String-Kopie nicht nur ein paar Zeiger umgebogen werden, sondern auch der komplette Speicher der Zeichenkette kopiert werden muß)
-
Ok, aber wie sieht es aus wenn ich einen CString sehr oft hintereinander in einer Methode bearbeite? Dann könnte doch ein Kopiervorgang, und das darauffolgende Bearbeitenk, schneller sein als mehrere Speicherzugriffe.
Ist vieleicht auch eine Frage wie da der Compiler optimiert. Vor allem ob es bei Call by Reference immer Speicherzugriffe sind. Kann ja sein das so ein string in den Cache ausgelagert wird.
-
Wenn du die lokale Kopie deines CString intensiv zerlegen willst, ohne Einfluss auf's Hauptprogramm zu nehmen, kommst du um Kopie nicht herum. Ansonsten dürfte der Zugriff über eine Referenz nur unwesentlich langsamer sein als der direkte Zugriff.
-
Was hat das ganze im Übrigen mit Speicherzugriffen zu tun? Ein String liegt immer im Speicher, sonst würde er nicht existieren.
Wo ist in Deinen Augen der Unterschied zwischen kopieren, bearbeiten, bearbeiten, bearbeiten und übergeben, bearbeiten, bearbeiten, bearbeiten. Richtig! Das Kopieren. Wieso sollte jetzt der Rest, der in beiden Fällen identisch ist, in einem Fall schneller gehen?!
EDIT:
Btw, wieviele Register soll so ein Durchschnitts-String kosten?
-
wenn du immer eine kopie brauchst (oder mit built-in arbeitest): pass by value
wenn du nie eine kopie brauchst: pass by referenze auf const
wenn du manchmal eine kopie brauchst: kommt drauf andie verwendung von referenzen auf const kann unter bestimmten bedingungen compiler-optimierungen verhindern.
es gab auch mal einen längeren artikel dazu (keine ahnung, wo ich jetzt suchen müsste, schau evtl. mal in die doku der boost operator library)
-
LordJaxom schrieb:
EDIT:
Btw, wieviele Register soll so ein Durchschnitts-String kosten?
Ok überzeugt

-
Chris++ schrieb:
Das ist jetzt wohl eher eine Frage an Compilerbauer. Was erzeugt mehr Overhead:
- das CString / std::string Objekt zu kopieren und mit einer lokalen kopie zu arbeiten
- oder diese Objekte per Call by Reference zu übergebenKommt drauf an, ob du den String verändern willst, ohne die Version im aufrufenden Code zu verändern. Im Zweifelsfall legst du dir aber besser im verarbeitenden (aufgerufenen) Code eine Kopie an.
[/quote]
Ist es beim letzteren nicht so, das der Prozessor immer (?) direkt auf die Speicheradressen mit dem Inhalt zugreifen muss? Und beim ersten Fall den Inhalt vieleicht in einem Register hält?
Oder hängt das nur wieder von der Benutzung ab.[/quote]Äh... Die Register sind 32 oder mit etwas Glück 64 Bit breit. Da passt kein String rein. Nein, in den Registern befindet sich auch nur ein Zeiger. Und wenn du einen Call-by-Reference machst, wird letztlich ein Zeiger auf das Objekt übergeben.
Wenn du Call-By-Value machst, also immer eine lokale Kopie anlegst, muss ALLES kopiert werden, das den String zu einem String macht. Schließlich handelt es sich um ein Objekt. Es muss also eine neue Instanz angelegt (Speicher reserviert) werden, die dann entsprechend des Inhalts der Quelle gefüllt wird.
Das ist definitiv nicht schneller, als mit einer Referenz zu arbeiten.
Eine Referenz ist letztlich auch nur eine "Zeiger-Kapselung" damit es für die Programmierer schwieriger ist, das System über die Klinge springen zu lassen.
-
Notiz für selbst: Beim nächsten Mal nicht mehr auf Fragen antworten, für die man seit 2 Stunden das Fenster offen hat...