Das deutsche QBasic- und FreeBASIC-Forum

[Thorben]

Moin

Gibt es eine funktion die schneller als CHR$() ist?

MFG Thorben

[Eternal_pain]

kommt drauf an, in welchem Zusammenhang...
_________________

[Thorben]

[Eternal_pain]

probier mal ob das schneller geht....

[Jojo]

klar, 1+1 ist zum beispiel schneller...

CHR ist hier nicht der bremsende faktor, sondern eher die schleife... wenn du einen langen string hast und den stück für stück neu zusammenbaust, dauert das lang...versuche, so viele daten wie möglich in einem befehl zu verarbeiten. CHR kann nur ein byte verarbeiten...
_________________
» Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.

[csde_rats]

[Jojo]

... was aber nichts anderes ist als CHR(0) + CHR(1) + CHR(2) <--- mehrere Befehle, NICHT einer wie z.B. in MID!
_________________
» Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.

[Wolfi30]

Hi!

Also wenn man die Stringbefehle mit Hilfe von Assembler nachbearbeitet kann man schonmal 30-50% Leistungssteigerung rausholen , da der Compiler die Variablen im Speicher ablegt und nicht mit Register arbeitet! Das kostet viele unnötige Taktzyklen, die man sich sparen kann.

Gruß wolfi

[helium]

Da sieht man wieder den klassischen Fehler: Ein Problem, dass sich mit O(n) lösen lässt wird mit einem Algorithmus gelöst, der O(n²) braucht. Statt einen sinnvollen Algorithmus zu suchen wird versucht mit irgendwelchen Micoroptimierungen rumzuhantieren (schnellere Chr$-Alternative suchen), oder noch schlimmer: Es wird einfach mal wild geraten, was denn das Problem sein könnte, statt nachzugucken, was denn das Problem ist.
_________________
Bevor Sie aufhören sich körperlich zu betätigen sollten Sie ihren Doktor befragen. Körperliche Inaktivität ist abnormal und gefährlich für Ihre Gesundheit.

[Wolfi30]

Klar zuerst muss die Performance mit dem bestmöglichen Algorithmus rausgeholt werden!

Es geht doch auch noch darum, ob was schneller geht oder nicht! Der Freebasic-Compiler optimiert halt nicht so gut! Ständiger unnötiger Overhead bei Funktionsaufrufen, wenn man sich das Assembler-File anschaut! Ich hab mir mal die String-Befehle mit Hilfe von Assembler nachgebaut und war halt überrascht von der Performance gegenüber den Vorimplementierten! Das rentiert sich bei vielen Aufrufen schon etwas weiter zu gehen! Und wer ganz hartnäckig ist benutzt Macros und Inline-Assembler!

gruß wolfi

[MisterD]

es ist nicht sinnvoll, den stringbefehl "konkatenation" hier zu verbessern, es ist sinnvoll, ihn einfach nicht zu benutzen. Direkt den String mit der fertigen länge erstellen und danach alle zeichen auf den richtigen wert setzen statt den string jedes mal komplett neu zu erstellen und ein zeichen mehr dranzuhängen ist die einzige lösung für das problem wie helium gesagt hat, O(n) - jedes zeichen einmal setzen, statt O(n²) - jedes zeichen einmal setzen und alle bisherigen dafür einmal kopieren, den unterschied kann man einfach nicht erreichen durch optimieren von operationen wie + oder chr()
_________________
"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
Edsger W. Dijkstra