Translate$

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    Unsere Datenschutzerklärung wurde aktualisiert. Mit der Nutzung unseres Forums akzeptierst Du unsere Datenschutzerklärung. Du bestätigst zudem, dass Du mindestens 16 Jahre alt bist.

    • Hallo,
      Ich bin ja nicht so fit in ASM.
      Ich bräuchte ein Translate$() für sehr große Bereiche.
      Wäre ja evtl. viel schneller, als daß man mit String$()
      zuerst einen riesengroßen String erzeugen muß.

      Vielleicht hat schon jemand sowas in der Schublade.
    • Teile den String in Einzelstrings von maximal 10KB Größe auf und ersetze dann mit Translate$ - das geht scheinbar sehr viel schneller.
      Ab Strings von 1MB Größe nimmt die Zeit scheinbar exponential zu.
      Ich will hoffen, dass ich beim Austesten gerade nichts falsch gemacht habe...
      ________________________________________________________

      PPFScanner PPFS Android MisterXMail@web.de
      Mfg AHT

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von AHT ()

    • AHT schrieb:

      Ab Strings von 1MB Größe nimmt die Zeit scheinbar exponential zu.
      So, wie ich es sehe, hängt es an den langsamen Schleifen und nicht mal an der
      Größe der Strings.

      Quellcode

      1. Declare String A[1000000], z
      2. Mat A[] = "Hallo, du, da !"
      3. CLS
      4. Print "Array ist gefüllt !"
      5. Print "Starte WhileLoop - Test....Taste"
      6. WaitKey
      7. WhileLoopTest()
      8. Print "Starte Move.... Taste"
      9. Waitkey
      10. Set("MoveListMode", 1)
      11. Move("ArrToList", A[])
      12. Print "Move ist fertig..."
      13. Waitkey
      14. Proc WhileLoopTest
      15. WhileLoop 0, SizeOf(A[]) - 1
      16. z = Translate$(A[&LOOP], ",", "|")
      17. EndWhile
      18. Print "WhileLoop ist fertig"
      19. EndProc
      20. MoveListProc
      21. Parameters String s, int index
      22. Declare String z
      23. If Get("MoveListMode") = 1
      24. z = Translate$(s, ",", "|")
      25. EndIf
      26. EndProc
      Alles anzeigen
      Sogar die MoveListProc scheint langsamer zu sein.


    • Doch - hängt an der Größe des Strings. Bei meiner Technik brauche ich für einen String von 1,3MB Größe mit reinem Translate$ 80 Sekunden - mit meiner Technik 0,655 Sekunden.

      Erhöhe ich die Stringlänge auf 2,6MB, braucht Translate$ bei mir 327 Sekunden, meine Technik ist in 2,3 Sekunden fertig.

      Verdoppele ich den String nochmals auf 5,2MB, braucht Translate$ bei mir 29 Minuten (1768 Sekunden), meine Technik ist in 7,4 Sekunden fertig.


      Optimale Größe für Translate$ scheint hier etwa 5KB an Stringgröße zu sein. Dann reagiert das Fenster noch vernünftig auf Messages und die Anzahl der Schleifendurchläufe sind noch nicht so groß, dass die ganze Sache Ewigkeiten dauert.
      ________________________________________________________

      PPFScanner PPFS Android MisterXMail@web.de
      Mfg AHT

      Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von AHT ()

    • Ich denke, er sucht nach einer Lösung, die Frank in seiner Listview.dll eingebaut hat.
      Tausch von Trennzeichen in einer csv-Datei.
      Für 5.931kB braucht die 22/100 sec.

      Quellcode

      1. text$="bic.csv"
      2. bytes&=@FileSize(text$)
      3. print "Bytes: "+str$(bytes&)
      4. print "Start:" + @Time$(1)
      5. If bytes&>0
      6. Dim bereich#,bytes&+1
      7. ReadFileQuick(addr(text$),bereich#,0,bytes&)
      8. ExchangeSeparator(bereich#,bytes&,@Ord(";"),@Ord("#"),1)
      9. print "Fertig:"+@Time$(1)
      10. ExchangeSeparator(bereich#,bytes&,@Ord("#"),@Ord(";"),1)
      11. CsvToListview(listview&,bereich#,bytes&,6)
      12. Dispose bereich#
      13. EndIf
      14. print "Zeilen:"+str$(GetLines(listview&))
      15. ShowListView(listview&,2,82,500,450)
      Alles anzeigen
      Bic-csv.png
    • THFR schrieb:

      Ich denke, er sucht nach einer Lösung, die Frank in seiner Listview.dll eingebaut hat.
      Ganz genau.
      Das geht so schnell, da kann man keine Zeit messen :

      Quellcode

      1. Declare Memory bereich, Long hdll, anz
      2. hdll = UseDLL("Listview.dll")
      3. ImportFunc(hdll, "ExchangeSeparator", "TranslateX")
      4. CLS
      5. Dim bereich, FileSize("E:\Liste.txt")
      6. Assign #1, "E:\Liste.txt"
      7. OpenRW #1
      8. anz = BlockRead(#1, bereich)
      9. Close #1
      10. Print "Fertig..."
      11. Print "Taste zum Austausch"
      12. WaitKey
      13. TranslateX(bereich, FileSize("E:\Liste.txt"), Ord(","),Ord("|"),1)
      14. Print "Fertig..."
      15. Waitkey
      16. Dispose bereich
      17. FreeDLL hdll
      18. End
      Alles anzeigen
      Dabei ist die Datei 47.744 KB groß.

    • Das wäre dann aber was ganz Anderes als das "echte" Translate$. Das muß ja auch beliebig viele Strings mit wahlfreier Länge durch einen String mit wahfreier Länge ersetzen und hat dann auch erst mal die neue Ziellänge zu ermitteln, den Speicher entsprechend zuzuweisen und dann nicht nur einzelne Bytes zu ersetzen, es muß ja alle Daten umschaufeln. Soll nur ein einzelnes Byte beliebig oft durch ein anderes Byt ersetzt werden, dann ist das recht einfach.

      Quellcode

      1. //TranslateX(Bereich#, Size&, OrgChar%, NewChar%)
      2. ASM "TranslateX", 4
      3. PUSH EBX
      4. PUSH ECX
      5. PUSH EDX
      6. PUSH ESI
      7. MOV EDI, Par1 // Adresse Quellstring
      8. MOV ECX, Par2 // Länge Quellstring
      9. MOV EBX, Par3 // Code Suchzeichen
      10. MOV EDX, Par4 // Code Ersatzzeichen
      11. MOV AL, BL
      12. MOV AH, DL
      13. XOR EDX, EDX // EDX löschen
      14. Suchen:
      15. OR ECX, ECX // Quelllänge 0?
      16. JZ IsLen // Länge 0 erreicht, String durch
      17. DEC ECX // Länge runter zählen
      18. SCASB
      19. JNZ Suchen // Byte nicht gefunden
      20. MOV [EDI - 1], AH // Ersetzen
      21. INC EDX // Ersetzen Zählen (kann entfallen)
      22. JMP Suchen
      23. IsLen:
      24. MOV EAX, EDX
      25. POP ESI
      26. POP EDX
      27. POP ECX
      28. POP EBX
      29. EndASM
      30. Declare Mem Bereich, String Test
      31. Test = "Does ost eon erster Teststrong, on dem was gewechselt word."
      32. DIM Bereich, 1000
      33. String Bereich, 0 = Test
      34. Print Test, Len(Test)
      35. Print Str$(TranslateX(Bereich, Len(Test), Ord("o"), Ord("i"))), " geändert:"
      36. Print String$(Bereich, 0)
      37. WaitInput
      Alles anzeigen




      Gruß Volkmar
    • Zum Ersetzen von mehr Zeichen würde ich die Sache aufteilen:
      Man muss sich natürlich etwas Gedanken darüber machen, wie die ganze Sache wirklich sicher läuft und alles ersetzt.
      Bei 5,2MB an String sind 29 Minuten echt die Kanone. :lol2:

      Danke für deinen Beitrag hier. War echt lustig, das mal auszutesten. Arbeite zum Glück seit einiger Zeit nicht mehr wirklich mit XProfan.
      Bitte nicht falsch verstehen - ist eine wirklich schöne Sprache zum Lernen von Programmierung unter Windows (wenn man das nicht beruflich braucht), eben weil die Sprache manche Sachen nicht zu einfach macht (und manche eben doch). Zum Schreiben von wirklichen Anwendungen taugt das aber seit Windows7 nicht mehr so wirklich.
      ________________________________________________________

      PPFScanner PPFS Android MisterXMail@web.de
      Mfg AHT

      Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von AHT ()

    • XProfan zwingt so zu verdammt guten, durchdachten Algorithmen. Woanders geht´s halt mit Brute Force ...

      Erforderlichenfalls kann man auch noch an XPSE denken, dort gibts ein "natives" Translate$(). Bei X4 wird man allerdings sehr viele
      {$PUSHKEYWORD param} brauchen, will man nicht ganz brutal mit {$NOERR} arbeiten. Mit dem Schalter kann man - beistrichgetrennt - Schlüsselworte als existent definieren, die XProfan 11 noch nicht kannte. Und um mit FOR NEXT und Quadint zu arbeiten, gibt es die JRPC.exe als Prä-Precompiler für iF´s XPSE mit X2 und X3, ich vermute aber auch mit X4: Link

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von p. specht ()

    • Bevor man zig andere Tools nutzt - die im Endeffekt auch nicht dazu führen, dass alles in der Sprache wirklich vernünftig funktioniert - ist es besser und einfacher (und billiger), eine andere Sprache zu nehmen (wenn man wirklich Anwendungen schreiben möchte).
      XProfan ist klasse, wenn man bestimmte Sachen tun möchte. Will man wirklich Programme schreiben, ist man besser bei anderen Sprachen aufgehoben.
      ________________________________________________________

      PPFScanner PPFS Android MisterXMail@web.de
      Mfg AHT
    • Interessant: Translate besteht ja aus t$[]=explode(string$,",") und x$=implode$(t$[],"|neuerTrenner|").
      Explode ist sehr flott, aber im Implode wird je neuem angehängtem Trenner ein String x$ erweitert. Das gibt bei 20000 Trennern 20000 neue Strings - gegen Ende jedesmal fast die volle Länge. HIER müsste man was machen mit ASM - nur müsste man dazu wissen, wie die Stringarrays angesprochen werden (statisch oder dynamisch macht auch noch einen Unterschied!
    • p. specht schrieb:

      XProfan zwingt so zu verdammt guten, durchdachten Algorithmen.
      Dazu noch:
      Im Prinzip empfinde ich das heutzutage eher als nervig, da viele Sachen davon in anderen Sprachen gar nicht oder in anderer Art nötig sind.
      Von ihrem Aufbau halte ich die Sprache immer noch für absolut gut.
      So was hier entwickele ich zuerst immer noch mit XProfan unter 32Bit:
      Bei XProfan (gerade bei meiner älteren Version) muss ich mir zum Entwickeln solcher Sachen sehr viel mehr durchlesen (und wirklich verstehen) als ich das in der Sprache muss, in der ich das dann verwendet habe (ist im PPFScanner eingebaut).
      Wenn etwas nicht läuft (das war natürlich auch bei der Entwicklung dieser Sache so), weiß ich dann sehr genau, warum es so nicht geht und ob ich etwas anderes tun kann, damit der Code am Ende funktioniert.
      Ich habe also am Anfang zwar sehr viel mehr Arbeit, habe aber wesentlich größere Chancen, am Ende etwas zu haben, was funktioniert.
      Im Endeffekt sind dann aber mit XProfan gar keine Programme wirklich machbar, in denen man so etwas richtig nutzen kann. Da man aber dann verstanden hat, was man da getan hat, ist auch die Umsetzung in andere Sprachen und auf 64Bit kein Problem.

      Sehr interessant finde ich auch, das XProfan eine interpretierende Sprache ist. Man muss die ja gar nicht nur dazu nutzen, um eigenständige Programme zu schreiben.

      p. specht schrieb:

      HIER müsste man was machen mit ASM
      Man müsste gar nichts. Die Sprache ist im Prinzip zum Entwickeln von Anwendungen seit Vista tot.
      ________________________________________________________

      PPFScanner PPFS Android MisterXMail@web.de
      Mfg AHT