Hallo Raketenwilli,
Wer macht sowas in PHP?
Ich 😉
Und in unter 2 Minuten Rechenzeit auf einem normalen modernen Hobel ist das wohl akzepabel.
Ich habe mir deine Optimierungsvorschläge mal angeschaut. Zum testen habe ich mein PHP Script bei Wort 65000 starten lassen, der Treffer ist bei 67504. Die Parallelscripte habe ich weggelassen. Damit ergeben sich Testlaufzeiten von etwas über 10s.
- md5 mit false aufrufen und hex via == vergleichen: 14,3s
- md5 mit false aufrufen und hex via === vergleichen: 13,1s
- md5 mit true aufrufen und binär via == vergleichen: 12,9s
- md5 mit true aufrufen und binär via === vergleichen: 12,3s
Da ist also Potenzial für ca 14% Laufzeitersparnis.
Die Abfrage auf erfolgreichere Parallelprozesse habe ich so gelöst, dass der Finder eine "found.txt" schreibt und die übrigen abbrechen, sobald sie diese Datei finden. Das tun sie nicht in jedem Durchlauf für Wort 1, sondern nur alle 200 Worte, sonst verliert man gleich wieder anderthalb Prozent (also fast nix 😉).
Was deutlich Wirkung hat, ist die PHP Version. Mit PHP 7.4 dauert die Nummer fast 2s länger, und ein historisches PHP 5.6, das ich hier noch im Museum habe, brauchte doppelt so lange. Der opcache.jit bringt ebenfalls ca 2s Laufzeitgewinn.
Was eher nichts bringt, ist foreach statt for($j=0; ...) als Schleifensteuerung. Ich hatte zuerst for ($j=0; ...) drin und habe es auf foreach umgestellt, das war unterhalb der Messschwelle.
Wirkung hat auch der Einsatz von SPLFixedArray. Es ist ein paar Prozent langsamer 😉. Ich müsste jetzt noch schauen, wie sich die Sache unter C# mit .net verhält, glaube aber, dass es nicht viel sein kann. Die Implementierung der MD5 Funktion dürfte der kritische Pfad sein.
Rolf
sumpsi - posui - obstruxi