Performance-Analyse der neuen Datenstruktur "Map"

    Geschwindigkeit ist keine Hexerei?

    Ich habe, seit Jahrzehnten, auf allen Rechnern RamDisks. Finde das seit ewigen Zeiten extrem praktisch. Man kann jede Menge Files täglich darin erstellen, nach dem Neustart sind sie weg. Was die einen als potentiellen Datenverlust bezeichnen finde ich praktisch. Was das mit Geschwindigkeit zu tun hat?

    Die eine oder andere Software bekommt, im wahrsten Sinne des Wortes, Flügel, wenn sie in einer RamDisk läuft. Ich habe z.B. ein Autoit Programm, dass aus bestimmten Dokumenten PDFs macht. Was auf einer normalen Festplatten 25 Minuten dauert, geht in der RamDisk in 7-10 Minuten.

    Speed und RamDisk gehen da also Hand in Hand

    So long

    Peter

    Hinweise auf Suchmaschinen finde ich überflüssig - wer fragt hat es nicht gefunden oder nicht verstanden. Die Antwort gibt sich oftmals schneller als der Hinweis auf Dr. Goggle & Co.

    Ab 19-10-22 ergänzt um:

    Die Welt wird nicht bedroht von den Menschen, die böse sind, sondern von denen, die das Böse zulassen. (Albert Einstein)

    Nun wir reden im Grunde über 2 verschiedene Ebenen von Performance.
    Einmal um die Grenzen die die Hardware setzt und zum anderen wie weit die Software optimiert ist um diese Grenzen auszureizen.
    Das Problem mit den Array-Indizes ist ein klares Beispiel für den Fall, dass die Software weit entfernt ist von einer möglichst optimalen Ausnutzung der vorhandenen Hardwareleistung.

    Deine Methode mit der Ramdisk hingegen ist eine Methode die Leistung der Hardware höher zu setzen - genauer die vom Speichermedium, welches einfach durch ein schnelleres ersetzt wird.
    Natürlich könnte man die Leistung mit derartigen Dingen je nach Anwendung (für die Problematik der Array-Indizes nützt die Ramdisk konkret nichts) absolut steigern. Relativ bleibt sie aber weiterhin bescheiden.
    Wenn die Software vorher nur 5% der möglichen Performance, welche die Hardware hergibt ausgereizt hat, dann ist sie mit potenterer Hardware (z.B. RAM statt einer HDD) womöglich absolut 10x so schnell wie vorher, aber reizt immer noch nur 5% des eigentlichen Potentials aus.


    Kurz: Wir interessieren uns für Lösungen des eigentlichen Problems - nicht für Workarounds.

    Zitat von BugFix

    Sorry an AspirinJunkie , wenn wir hier etwas OT gehen.

    Das ist nicht OT - genau solche Performancediskussionen waren doch das Thema des Threads.

    AspirinJunkie

    da hast Du schon recht. Aber ab und an, sind profane Hilfsmittel besser als gar keine. Bei einem Autorennen ist es auch egal ob Du wegen schnellerer Boxenstops oder wegen mehr PS gewinnst - hauptsache erster :)

    LG

    Peter

    Hinweise auf Suchmaschinen finde ich überflüssig - wer fragt hat es nicht gefunden oder nicht verstanden. Die Antwort gibt sich oftmals schneller als der Hinweis auf Dr. Goggle & Co.

    Ab 19-10-22 ergänzt um:

    Die Welt wird nicht bedroht von den Menschen, die böse sind, sondern von denen, die das Böse zulassen. (Albert Einstein)

    Zitat von AspirinJunkie

    Kurz: Wir interessieren uns für Lösungen des eigentlichen Problems - nicht für Workarounds.

    So ist das...

    Wenn durch eine Methodenänderung/Umstrukturierung/Umprogrammierung der Faktor 2 erreicht werden kann, dann wird mir als hauptberuflicher Optimierer schon warm ums Herz :saint:

    Die Frage ist, ob der Dev davon wissen will, und ob er Problem- oder Lösungsorientiert arbeitet!? Ich jedenfalls bin immer froh, wenn ich Rückmeldung erhalte wenn etwas NICHT funktioniert, bzw. jemand eine gute oder bessere (als meine) Idee hat. Nur so kann man sich und den Ablauf verbessern. Das übliche ist aber, wenn problemorientierte Leute dann ein riesen Fass aufmachen, um von einem Ablauf, der bei 95% Erfolgsquote läuft, noch 0,2% "MEHR" rauszuholen....wobei eigentlich jeder wissen sollte dass es immer schwieriger wird, einen bereits optimierten Prozess weiter zu verbessern. Wenn überproportional viel Ressourcen, Manpower und Equipment benötigt wird, dann lohnt der Aufwand einfach nicht.

    Ich bin da pragmatisch: funktioniert, ist schnell, einfach und gut umzusetzen--->MACHEN! Ansonsten ans Ende der Prioritätenliste :whistling:

    Zitat von AspirinJunkie

    Das Problem mit den Array-Indizes ist ein klares Beispiel für den Fall, dass die Software weit entfernt ist von einer möglichst optimalen Ausnutzung der vorhandenen Hardwareleistung.

    Das gilt nicht nur für die Array-Indizes! Wobei ich ganz klar sagen muss, dass AutoIt, obwohl seit Jahren nicht mehr "weiterentwickelt" (ich rede nicht von dem immer mal implementierten Spielkram, siehe Thema ^^) wurde, ziemlich gut und "relativ" bugfrei läuft. "Richtige" Bugs habe ich jedenfalls schon seit Jahren nicht mehr gemeldet....und den Rest spare ich mir, um meine Nerven zu schonen 8o

    Zitat von BugFix

    Ist aber nur eine Vermutung - in die inneren Abläufe können wir ja leider nicht reinschauen.

    Hehe....ob ich das überhaupt will?! Nicht vorzustellen was passieren würde, sollte jemand sich näher damit befassen und entsprechend "atemberaubende" Änderungen aufzeigen....mimimimimi.... :rofl: