Geschwindigkeit

[helpy]

否則，您不會有任何問題，對不對？

==> Google Translate: "Andernfalls werden Sie keine Probleme haben, nicht wahr?"

[Kiffi]

否則，您不會有任何問題，對不對？

==> Google Translate: "Andernfalls werden Sie keine Probleme haben, nicht wahr?"

==> asiatisch-ungarisches Phrasenbuch: "Mein Luftkissenfahrzeug ist voller Aale"


tlhIngan Hol vIjatlhaHbe’

[RSBasic]

So nun zurück zum Thema, sonst muss ichs abtrennen.

[Kiffi]

So nun zurück zum Thema, sonst muss ichs abtrennen.

Aye, Aye, Sir!

[...] Wen das funktioniert, gehört so ein Stringbuilder nicht nativ in die PureBasic Sprache ?

Nein, da der StringBuilder hier eben wieder nur einen Vorteil in eben genau diesem einem Fall bringt (Immer wieder vergrößern eines Strings).

Stringverknüpfungen gehören IMO zu den nicht selten genutzten Funktionalitäten eines Programmes.
Fast alle 'größeren' Programmiersprachen bieten eben aus diesem Grund einen StringBuilder oder ähnliches
an. Ich persönlich würde mich schon freuen, wenn es sowas in PB nativ geben würde...

Grüße ... Kiffi

[Thorium]

Naja, meist ist so ein StringBuilder schlicht nicht nötig.

Beispiel: Ich habe für meinen Job ein Programm geschrieben, welches NC-Programme einliesst analysiert und Änderungen vornimmt: Platzhalter ersetzt, Zeilen einfügt, Zeilen entfernt, Zeilen verschiebt/kopiert. Verschiedene Versionen des Programm erzeugt, Zeilen neu durchnummeriert mit korrektur von Sprungbefehlen. Selbst bei 300kb NC-Programmen läuft das ganze ohne merkbare Wartezeit ab und ich habe nur PB-Funktionen benutzt und nix mit Zeigern, Puffern oder ASM optimiert.

Wer wirklich mehr Performance brauchst kann sich sowas auch selbst programmieren, in vielen Fällen ist aber einfach die allgemeine Herrangehensweise schon unoptimal bei String-Performanceproblemen. Oder man arbeitet wirklich mit hunderten MB's an Text.

[_JON_]

Oh oh, bei diesem Beispiel ist Autoit hier 25 mal schneller
Und Autoit ist bloß eine Interpreter Sprache wo For-Next-Schleifen generell langsam sind.

Weiß jemand wie Autoit das handhabt?

[lite]

Hallo

Aufgabe: schreibe 30000 mal ein Buchstaben in eine Variable.

Hier mein Test:

Native mit PureBasic: 4760 ms
Autoit: 335 ms
Lites Version mit PB: 16 ms

Bitte in unicode kompalieren.

Code: Alles auswählen

#Size = 30000;0;0

MessageRequester("SpeedTest","Purebasic native, bitte warten")
a$=""
Time = ElapsedMilliseconds()
For n = 1 To #Size
  a$+"w"
 Next
Time1 = ElapsedMilliseconds()-Time

;Debug time1

MessageRequester(Str(time1),a$)


Procedure AddString(*mem,string$)
  size.f=MemoryStringLength(@string$)*2
  alt.f = MemorySize(*mem)
  *Mem = ReAllocateMemory(*mem, alt+size)
  ;If *mem =0: MessageRequester("*mem","error"): EndIf
  CopyMemory(@string$, *mem+alt-2, size)
ProcedureReturn *mem
EndProcedure

MessageRequester("SpeedTest","Lites Version, bitte warten")
*mem = AllocateMemory(2)
Time = ElapsedMilliseconds()
For n = 1 To #size
  *mem =AddString(*mem,"w")
Next
Time1 = ElapsedMilliseconds()-Time
txt$ = PeekS(*mem)
Debug "----"
Debug time1

MessageRequester(Str(time1),txt$)

Zu "Findstring"
Was noch negativ ist, da wird eine neuer Parameter in FindString hinzugefügt.
"PB_String_NoCase", er ist aber langsamer als wen man 2 Befehle kombiniert.

FindString(LCase("PureBasic"), LCase("bas")) <---- schneller
FindString("PureBasic", "bas",1,#PB_String_NoCase) <---- langsamer

Damit hat der Parameter keinen Sinn mehr.

Grüße
Lite

[Thorium]

Wobei immernoch nicht klar ist was du eigentlich bezwecken möchtest. Es kann gut sein das es ganz andere Herangehensweisen an das Problem gibt und du garnicht 30k Strings zusammenfügen brauchst.

Dein erster Code in diesem Thread zeigt z.B. das du die komplette Datei als einem String behandelst und dann mühselgig in Zeilen, usw. unterteilst. Wenn du eine Datei zeilenweise verarbeiten möchtest, ließ sie direkt in eine linked list ein, somit kannst du jede Zeile unabhängig manipulieren.

30k Strings zusammenzufügen kommt mir jedenfalls ein bissel Overkill vor. Ich würde gerne mal wissen wofür du das einsetzt. Ich hab sowas noch nie gebraucht.