Re: Performance
Norbert Eder hat gesagt.:
Performance:
Es ist IMMER wichtig schnellen Code zu fabrizieren - unabhängig ob da viele Funktionen in der Software sind oder nicht. Kein User möchte unnötig lange auf etwas warten. Des weiteren sei eines noch dazugesagt: Schneller Code muss nicht zwangsweise kurz sein. Oft ist es besser gewisse Alogrithmen ordentlich auszuprogrammieren, erst dann sind sie wirklich schnell.
Das sind wir ja einer Meinung.
Norbert Eder hat gesagt.:
Zu dem ReadLine() "Problem":
ReadLine löscht nichts (ist in diesem Zusammenhang, cosmo, der falsche Ausdruck). Und selbst wenn noch gesplittet werden muss, warum in eine eigene String-Variable schreiben (die jedes mal neu instanziert wird) wenn das gleich mit dem ReadLine geht? -> ReadLine().Split(....). Dann bleibt zwar das Array zu instanzieren, aber der String (der ja ohnehin durch ReadLine schon erstellt wird, muss kein zweites Mal instanziert werden. Somit braucht das Teil wesentlich weniger Speicher und reagiert auch entsprechend performanter. Davon abgesehen ist es noch besser mit Byte-Arrays zu arbeiten.
Da bin ich mit Dir auch einer Meinung.
Sicher weiss ich auch das man direkt auf die zurückgegebenen Objekte von Funktionen zugreifen kann.
Soviel Erfahrung solltest mir langsam aber schon zutrauen.
Für den Fall das der String an dieser Stelle nocheinmal gebaucht wird,
er evtl irgendwann mal gesplittet wird, ist es doch notwendig,
sich diesen erstmal irgendwo abzulegen.
Das war einzig und allein mein Anliegen.
Sicher ist die direkte Variante hier absolut treffend.
Und ich glaub zu verstehen was Du meinst.
Ich sollte darauf achten so wenig zu instanzieren wie es nur geht
und ein schon vorhandenes String-Objekt verwenden,
sofern ich den String mehrmals brauche,
um den geholten String von da aus weiter zu verwenden.
Ich hoffe ich habe das jetzt vertstanden. :-(
lg, cosmo
