XProfan X5

    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.

    • naja, zumindest bleibt der Hauptprozess derweil weiterhin handlungsfähig und bedienbar.

      Die Dateisuche selbst wird wahrsch. weiterhin seine Zeit brauchen. Aber vllt. lässt sich der 2. Prozess noch etwas gezielter auf die Dateisuche optimieren.
      Mit Assembler hab ich keine Erfahrungen, aber vllt. könntest du so ein Schnipsel im 2. Prozess verwenden/einbauen, der zumindest einen Teil der Arbeit übernimmt...
      Gruß Jörg

      Ideen gibt es viele - man muß sie nur haben...
      Win7-Pro / Linux Mint
    • Ich hab leider keine Ahnung von Assembler. Aber es wurde mir schon helfen, weil ich 14 Dateisuchen nacheinander abarbeite, da kann ich vielleicht ein paar parallel laufen lassen.
      XProfan-Semiprofi (XProfan X4a+XPIA+LemonEd)
      Ryzen 1700X/MSI B350 PC MATE/16GB RAM@2933MHz/Radeon HD7770 OC/Creative X-Fi XTreme Music/90TB HDD+256GB Samsung 960 EVO/28" Samsung 4k
      TerraMaster F4-420 mit 16TB
      XBox Classic/360S/One S/One X Scorpio Edition/PS3 Super Slim 500GB/PS4 Pro (XBL-ID: jacdelad, PSN: jacdelad84)
      OnePlus 6 8GB/256GB
      jacdelad.bplaced.net
    • Jac de Lad schrieb:

      Bei mir geht's um 400000 Dateien und mehr.
      Na, das nenne ich mal eine Hausnummer.
      Da wird dir AddFiles sowieso nicht weiterhelfen,
      da die interne Listboxliste nur ca. 250.000 bis 260.000
      Einträge aufnehmen kann. Das geht dann nur mit einem
      dyn. String-Array.

      Man könnte mit Bordmitteln und windowseigenen
      Mitteln (cmd + dir) da was zusammendröseln. An sowas hätte
      ich da gedacht :

      Quellcode

      1. Declare String Files[]
      2. 'SetSize Files[], 400000
      3. Cls
      4. ChDir "C:\Windows"
      5. WinExecWait(GetEnv$("COMSPEC") +" /c Dir *.exe > E:\Files.txt", 0)
      6. Set("MoveListMode", 1)
      7. Move("FileToList", "E:\Files.txt")
      8. WhileLoop SizeOf(Files[]) - 1
      9. Print Files[&LOOP]
      10. EndWhile
      11. WaitKey
      12. MoveListProc
      13. Parameters String s, Int i
      14. If Get("MoveListMode") = 1
      15. Files[i] = s
      16. EndIf
      17. EndProc
      Alles anzeigen
      Pfade mußt du dir halt noch anpassen. Hier hättest du die schnelle Schleife
      von Move in der Movelistproc und halt die Ausgaben von cmd + Dir in einer
      Datei. Dürfte wohl am schnellsten sein. Ohne die API, die auch hinter dem
      DIR-Befhel steckt, kommst du sowieso nicht an die Dateien ran.
      Da hilft auch kein ASEMBLER (ASM). Stellt sich noch die Frage, ob die Dateien
      in einem einzigen Ordner sind oder ob du noch zwischendrin den Ordner mehrmals
      wechslen mußt.

      Vielleicht hilft dir das weiter :??:
    • Danke.
      Den Code habe ich schon. Es werden auch nicht 400000 Ergebnisse gefunden, sondern an 14 Orten je um die 400000 Dateien durchsucht, Tendenz steigend. Mein Code funktioniert an sich, ich will die Aufrufe jetzt nur parallelisieren.
      XProfan-Semiprofi (XProfan X4a+XPIA+LemonEd)
      Ryzen 1700X/MSI B350 PC MATE/16GB RAM@2933MHz/Radeon HD7770 OC/Creative X-Fi XTreme Music/90TB HDD+256GB Samsung 960 EVO/28" Samsung 4k
      TerraMaster F4-420 mit 16TB
      XBox Classic/360S/One S/One X Scorpio Edition/PS3 Super Slim 500GB/PS4 Pro (XBL-ID: jacdelad, PSN: jacdelad84)
      OnePlus 6 8GB/256GB
      jacdelad.bplaced.net
    • dann würd ich sogar dafür einen 3. 4. 5. Prozess parallel starten. Jeder übernimmt ein ihm übergebenes Suchverzeichnis(oder 2-3) & alle suchen halt parallel um die Wette ;-) .
      Der Hauptprozess selbst sucht garnix, sondern wartet, bis die laufenden Nebenprozesse artig ihre Suchergenisse als Message an die Ereignisschleife des Hauptprozesses melden und dann die Ergebnisse weiterverarbeitet...
      Gruß Jörg

      Ideen gibt es viele - man muß sie nur haben...
      Win7-Pro / Linux Mint
    • Danke Jörg, genau so werde ich es machen (und mache es an anderer Stelle auch schon, dort werden 26 Ordner kontaktiert. Wenn sie nicht erreichbar sind dauert das bis zu 30 Sekunden. Da das parallel läuft ist es egal wie viele ich kontaktiere, es dauert immer nur maximal 30 Sekunden). ;-)
      XProfan-Semiprofi (XProfan X4a+XPIA+LemonEd)
      Ryzen 1700X/MSI B350 PC MATE/16GB RAM@2933MHz/Radeon HD7770 OC/Creative X-Fi XTreme Music/90TB HDD+256GB Samsung 960 EVO/28" Samsung 4k
      TerraMaster F4-420 mit 16TB
      XBox Classic/360S/One S/One X Scorpio Edition/PS3 Super Slim 500GB/PS4 Pro (XBL-ID: jacdelad, PSN: jacdelad84)
      OnePlus 6 8GB/256GB
      jacdelad.bplaced.net
    • Ich glaube nicht, dass es geschwindigkeitstechnisch etwas bringt, diverse Prozesse mit der Suche zu beauftragen. Da springt die Festplatte dann wild hin und her, was die Sache ausbremsen dürfte. Ein einziger Prozess, der das geordnet abarbeitet, dürfte am effizientesten sein.
      Ich frage mich allerdings, wie die Ergebnisse an das Hauptprogramm zurückgegeben werden sollen bei getrennten Adressräumen. Jedes gefundene File per Message? Das scheint mir eher eine Sache für einen Thread zu sein... Aber genug davon. ;-)

      Beste Grüße, Jens-Arne

      Edit:
      Nochmal etwas geordneter:
      Wenn ein Programm mit 5 Prozessen arbeitet, bekommt es insgesamt etwas mehr Prozessorzeit, als wenn nur das Hauptprogramm und ein Prozess arbeiten, da Windows jedem Prozess irgendwann etwas Zeit zuteilt, was bei 5 Zusatzprozessen, die einem gehören, etwas mehr zu Lasten der 1000 anderen Prozesse geht, die sowieso laufen. Insofern würde das Gesamtprogramm etwas "schneller".
      Aber wenn jeder Prozess ein eigenes Verzeichnis abarbeitet, wird bei jedem Sprung zu einem der einem gehörenden Prozesse wieder ein anderes Verzeichnis bearbeitet, was bedeutet, dass sich der Festplattenkopf neu positionieren muss. Wenn aber ein einziger Prozess alle Verzeichnisse nacheinander abarbeitet, wäre das nicht der Fall - jedenfalls nicht bei einer defragmentierten Platte. Das dürfte also viel schneller gehen, als ein paar tausenstel Prozessorzeit zu "erbeuten", während der Festplattenkopf physische Bewegungen ausführen muss, die man vermeiden könnte.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Jens-Arne ()

    • Ach Jens-Arne,
      das weiß ich doch. Meine Dateien liegen aber in einem Netzwerk. Das bringt auf jeden Fall was. Wie ich die Rückgabe der Dateinamen veranstalte weiß ich auch schon, das gebe ich hier aber erst zum Besten, wenn ich es probiert habe.
      Außerdem haben SSDs gar keine Köpfe mehr. ;-)
      XProfan-Semiprofi (XProfan X4a+XPIA+LemonEd)
      Ryzen 1700X/MSI B350 PC MATE/16GB RAM@2933MHz/Radeon HD7770 OC/Creative X-Fi XTreme Music/90TB HDD+256GB Samsung 960 EVO/28" Samsung 4k
      TerraMaster F4-420 mit 16TB
      XBox Classic/360S/One S/One X Scorpio Edition/PS3 Super Slim 500GB/PS4 Pro (XBL-ID: jacdelad, PSN: jacdelad84)
      OnePlus 6 8GB/256GB
      jacdelad.bplaced.net
    • Neu

      Es klappt, aber nur über FileMaps. Da ist der Speicheraufwand recht hoch, weil ich ja vorher nicht weiß wieviel Speicher ich reservieren muss.
      @RGH: Wäre es möglich die "Move"-Funktion mit "StrToHandle" und ähnlichem ohne Nutzung der internen Liste zu erweitern? Ich weiß, dass ich das natürlich selbst machen kann, aber direkt von XProfan kommend wäre das sicher um ein Vielfaches schneller.
      @Jens-Arne: Verstehe ich das richtig, dass ich bei der Benutzung von Threads (wenn XProfan das könnte, bzw. so wie es üblich ist) anstelle von Prozessen komplett auf die Steuerelemente und Variablen des Hauptprogramms zugreifen könnte?
      XProfan-Semiprofi (XProfan X4a+XPIA+LemonEd)
      Ryzen 1700X/MSI B350 PC MATE/16GB RAM@2933MHz/Radeon HD7770 OC/Creative X-Fi XTreme Music/90TB HDD+256GB Samsung 960 EVO/28" Samsung 4k
      TerraMaster F4-420 mit 16TB
      XBox Classic/360S/One S/One X Scorpio Edition/PS3 Super Slim 500GB/PS4 Pro (XBL-ID: jacdelad, PSN: jacdelad84)
      OnePlus 6 8GB/256GB
      jacdelad.bplaced.net
    • Neu

      Jac de Lad schrieb:

      anstelle von Prozessen komplett auf die Steuerelemente und Variablen des Hauptprogramms zugreifen könnte?
      Steuerelemente von Windows sind nicht Threadsafe. Auf Variablen kann man nur zugreifen, wenn diese gesichert (z.B. per Mutex) wurden. Das einfachste ist es, die GUI nur in einen Thread zu handhaben und diesen zur Aktualisierung mit Messages zu versorgen, wobei dieser sich dann selber aktualisiert.

      Dafür sollte man dann aber eine Programmiersprache nutzen, die dafür geeignet / in der Lage ist.
      Gruß Thomas

      "Die deutsche Rechtschreibung ist Freeware, du darfst sie kostenlos nutzen – Aber sie ist nicht Open Source, d. h. du darfst sie nicht verändern oder in veränderter Form veröffentlichen."
      ComputerInfo für PPF
    • Neu

      Zugreifen auf Steuerelemente klappt schon.
      Da mußt du bei pExec das Handle mit übergeben.

      Aber ob es in deinem Falle, wegen des hohen
      Datenvolumens, sinnvoll ist ?

      Quellcode

      1. Declare Handle btn1, btn2, btn3, grid, Long ende, pid
      2. Window 640, 400
      3. btn1 = Create("Button", %HWnd, "Suspend", 10, 10, 80, 25)
      4. btn2 = Create("Button", %HWnd, "Resume", 100, 10, 80, 25)
      5. btn3 = Create("Button", %HWnd, "Ende", 500, 10, 80, 25)
      6. grid = Create("GridBox", %HWnd, "Spalte 1;0;80;Spalte 2;0;80;Spalte3;0;80", 0, 10, 80, 280, 200)
      7. ende = 0
      8. pid = 0
      9. UserMessages $1000
      10. pid = pExec("|Schleife", %HWnd, grid)
      11. WhileNot ende
      12. WaitInput
      13. If Clicked(btn1)
      14. Process("Suspend", pid)
      15. ElseIf Clicked(btn2)
      16. Process("Resume", pid)
      17. ElseIf Clicked(btn3)
      18. Ende = 1
      19. EndIf
      20. If %UMessage = $1000
      21. MessageBox("Schleife hat aufgehört !", "Info", 0)
      22. EndIf
      23. EndWhile
      24. If pid > 0
      25. Process("Kill", pid, 0)
      26. EndIf
      27. End
      28. Proc Schleife
      29. Parameters Handle win, tabelle
      30. Declare Long i
      31. For i, 1, 10
      32. WhileLoop 1, 10
      33. AddString(tabelle, Str$(&LOOP) + "|" + Str$(&LOOP * 2) + "|" + Str$(&LOOP * 3))
      34. Sleep 100
      35. ' Das Sleep ist hier nur drin, damit man den Fortschritt und
      36. ' damit die Anzeige in der Tabelle besser sieht. Andernfalls
      37. ' rutscht es zu schnell durch.
      38. EndWhile
      39. EndFor
      40. SendMessage(win, $1000, 0, 0)
      41. EndProc
      Alles anzeigen
      Man könnte auch eine unsichtbare Gridbox (Create("Grid",...) ) zur Aufnahme der
      Werte nehmen.

    • Neu

      @ts-soft: Mein Programm startet alle Aufrufe und wartet, bis sie fertig sind. Regelmäßig wird geprüft, ob die Prozesse noch laufen. Ist einer fertig werden die Daten verarbeitet, danach wird wieder geprüft ob einer fertig ist. Da brauche keine weitere Synchronisation stattfinden.
      @H.Brill: Jain, denn es funktioniert nur mit SetText, GetText$, AddString, InsertString und SelectString. Letztere auch nur mit Großboxen, nicht mit den eigentlich schnelleren Listboxen.
      XProfan-Semiprofi (XProfan X4a+XPIA+LemonEd)
      Ryzen 1700X/MSI B350 PC MATE/16GB RAM@2933MHz/Radeon HD7770 OC/Creative X-Fi XTreme Music/90TB HDD+256GB Samsung 960 EVO/28" Samsung 4k
      TerraMaster F4-420 mit 16TB
      XBox Classic/360S/One S/One X Scorpio Edition/PS3 Super Slim 500GB/PS4 Pro (XBL-ID: jacdelad, PSN: jacdelad84)
      OnePlus 6 8GB/256GB
      jacdelad.bplaced.net
    • Neu

      Auch als Thread sollte das in meinem Fall kein Problem sein. Ich starte ein Bündel Threads und warte bis sie fertig sind. Erst wenn ein Thread fertig ist verarbeite ich seine Daten weiter.
      XProfan-Semiprofi (XProfan X4a+XPIA+LemonEd)
      Ryzen 1700X/MSI B350 PC MATE/16GB RAM@2933MHz/Radeon HD7770 OC/Creative X-Fi XTreme Music/90TB HDD+256GB Samsung 960 EVO/28" Samsung 4k
      TerraMaster F4-420 mit 16TB
      XBox Classic/360S/One S/One X Scorpio Edition/PS3 Super Slim 500GB/PS4 Pro (XBL-ID: jacdelad, PSN: jacdelad84)
      OnePlus 6 8GB/256GB
      jacdelad.bplaced.net
    • Neu

      Hatte ich auch probiert, ging bei mir nicht. Im Endeffekt war Move inner noch um Längen schneller.
      Ich muss für bis zu 26 Ordner auf verschiedenen Rechnern in einem Netzwerk bestimmte Dateien auflisten. Diese Liste wird dann weiterverarbeitet. Bisher verläuft das seriell, ich will das parallelisieren. Jeder Ordner legt seine Dateinamen in einer eigenen Liste an, die Listen dürfen auch nicht vermischt werden.
      XProfan-Semiprofi (XProfan X4a+XPIA+LemonEd)
      Ryzen 1700X/MSI B350 PC MATE/16GB RAM@2933MHz/Radeon HD7770 OC/Creative X-Fi XTreme Music/90TB HDD+256GB Samsung 960 EVO/28" Samsung 4k
      TerraMaster F4-420 mit 16TB
      XBox Classic/360S/One S/One X Scorpio Edition/PS3 Super Slim 500GB/PS4 Pro (XBL-ID: jacdelad, PSN: jacdelad84)
      OnePlus 6 8GB/256GB
      jacdelad.bplaced.net
    • Neu

      du kriegst ja von den Nebenprozessen nach & nach per Message die Fertig-Meldung.
      Diese notierst du dir im Hauptprozess.
      Jeder Prozess hat bis dahin ja seine Dateinamen in einer Liste/Array (was auch immer) gespeichert und baut daraus einen String (zB. Name1|Name2|Name3|usw.)

      Vom Hauptprozess schickst du nun an einen "fertigen" Prozess die Message "schick mir das"
      Jetzt schreibt der aufgerufene Prozess den String einfach in die zuvor geleerte Zwischenablage & ruft zum Hauptprozess "ist da..."

      Der Hauprprozess holt sich dort den String ab und "prügelt" ihn in eine beliebige Liste/Array
      (gibt doch sogar entsprechende Funktionen, die das in einem Ruck machen, oder?)

      Dann "schreit" der Hauptprozess den nächsten fertigen Nebenprozess an: "schick mir das" - usw. :-)

      Edit:
      Das heißt, die Nebenprozesse suchen alle eifrig parallel, melden das, und der Hauptprozess sammelt nacheinander die Ergebnisse ein. Dabei müßtest du ja nicht warten, bis der letzte Prozess fertig ist, sondern kannst nach der ersten Fertig-Meldung anfangen, die Strings abzuholen.

      Edit_2:
      das gleiche Schema würde auch mit einer Speicherdatei zwischen den Prozessen funktionieren.
      Mußt halt vorher ausrechnen, wieviel Platz ein Prozess maximal benötigen würde. Dann 50% Sicherheit dazu - dürfte ja bei Text nicht sooo hoch ausfallen. (RAM ist ja reichlich vorhanden :-) )

      Man könnte ja sogar mal schauen, welchen Platz ALLE Dateinamen verbrauchen würden. Und so groß dimmst du halt den Speicher.
      Dann könnten sogar alle Prozesse ihre Strings zugleich reinschreiben (jeder hat natürlich seinen eigenen Namen.)
      Das geht doch nicht so einfach, also immer hübsch einer nach den anderen ;-)
      Gruß Jörg

      Ideen gibt es viele - man muß sie nur haben...
      Win7-Pro / Linux Mint

      Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von JörgG ()

    • Neu

      So mache ich das, nur ohne Message und dass jeder Prozess sein eigenes FileMap bekommt. Aber mit Message geht natürlich auch, dann kann die Message gleich die gewünschte Größe mitliefern.
      XProfan-Semiprofi (XProfan X4a+XPIA+LemonEd)
      Ryzen 1700X/MSI B350 PC MATE/16GB RAM@2933MHz/Radeon HD7770 OC/Creative X-Fi XTreme Music/90TB HDD+256GB Samsung 960 EVO/28" Samsung 4k
      TerraMaster F4-420 mit 16TB
      XBox Classic/360S/One S/One X Scorpio Edition/PS3 Super Slim 500GB/PS4 Pro (XBL-ID: jacdelad, PSN: jacdelad84)
      OnePlus 6 8GB/256GB
      jacdelad.bplaced.net
    • Neu

      ok - jeder Prozess seine eigene FileMap - geht auch. Mußt dann aber höllisch aufpassen, das mit den ganzen Maps nicht durcheinanderkommst ;-)
      Aber ich würde sie dann vorher alle statisch in sicherer Größe anlegen und den Prozessen gleich zuordnen. Dann brauchst du dich später nur noch um das Abholen und Verarbeiten der Ergebnisse kümmern.
      Gruß Jörg

      Ideen gibt es viele - man muß sie nur haben...
      Win7-Pro / Linux Mint
    • Neu

      Das kann man ja schön in Arrays mit Strukturen verwalten.
      Da könnte dann auch die Größe der FileMap beim Erzeugen
      im Prozess festgehalten werden.


      Quellcode

      1. bereich# = FileMap("Map", H)
      2. SendMessage(win, $1000, SizeOf(bereich#), 0)
      Bei %UMessage unter &UWPARAM wird der Bereich dann dimensioniert.
      In &ULPARAM könnte man z.B. auch noch einen Index für ein Array im Hauptprogramm
      unterbringen. Oder halt noch einen sonstigen Wert. Bei so vielen Maps würde ich dann
      eher die Indexnummern eines Arrays als Namen verwenden (FileMap("Open", S) ).