Wann ist AutoIt nicht mehr die richtige Wahl

  • Hallo AutoIt Gemeinde,

    ich wollte mal eure Meinung hören ab welcher Projektgröße oder Projektart ihr nicht mehr
    zu AutoIt greifen würdet.

    Was würdet ihr dann stattdessen benutzen? C#, VB.net...

    Es wäre schön wenn ihr eure Meinung irgendwie begründen könntet.

    Ich habe kein spezielles Projekt im Kopf ist ganz allgemein gemeint, ab wann zieht ihr ein
    Strich und sagt bis hierhin Autoit und ab da benutze ich xy weil....

    Bin gespannt...

    Gruß Damion

    • Offizieller Beitrag

    Das lässt sich nicht so einfach beantworten.
    AutoIt ist (aufgrund der Tatsache, dass es sich um eine Interpretersprache handelt) geschwindigkeitsmäßig oftmals nicht ausreichend.
    Das macht sich aber erst bei umfangreichen Berechnungen (welcher Art auch immer) bemerkbar.
    Dafür kann man mit AutoIt sehr einfach Benutzeroberflächen erstellen und die Sprache ist leicht erlernbar.

    Ich würde sagen: Wer AutoIt mag, der wird es benutzen und wenn es geschwindigkeitsmäßig nicht reicht, dann werden die entsprechenden Funktionen eben in C++ oder Assembler geschrieben.

    Es ist also IMHO keine Frage ob "das oder das", sondern eher ein "der Teil in AutoIt und der andere Teil in C/Assembler".

  • Hi!

    Hier mal ein ziemlich beeindruckendes Beispiel, um Oscar's Aussage, was die Geschwindigkeit betrifft, zu untermauern.
    Das Programm ermittelt, ob die übergebene Zahl eine Primzahl ist, oder nicht.
    Die AutoIt Funktion _isPrime() tritt gegen eine identische Funktion in "C" geschrieben an, die sich in der DLL befindet.
    Die DLL musst du natürlich hier aus dem Anhang runterladen und in das gleiche Verzeichnis packen, wie das AutoIt Programm.

    Spoiler anzeigen


    Um dir die Wartezeit zu ersparen, hier sind die Ausgaben für die Zahl 2147483647:
    [Blockierte Grafik: http://i.imgur.com/nz5NEZL.png][Blockierte Grafik: http://i.imgur.com/y5sGb4n.png]


    Ich habe übrigens mal diese Berechnung in C, C++(.NET), C#, Java und Delphi gegeneinander laufen lassen.
    Waren alle ähnlich schnell mit leichtem Vorsprung für Delphi (vermute mal weil, Delpi nicht mit .NET "belastet" ist.

    *edit*
    Copy/Paste Fail beim Quellcode. Die Ausgabe für TRUE hatte eine fixen Wert anstatt einer Berechnung. Ist aber jetzt korrigiert. Sorry!

    Schönen Gruß, Friesel

  • Hallo,
    das kann ich natürlich nicht auf AutoIt sitzen lassen :P

    Folgendes Programm liefert das Ergebnis für die Zahl 2147483647 in 0.05 Sekunden - und das auf meiner langsamen Kiste mit noch gefühlten 10 weiteren Anwendungen die laufen.

    :rock:

    Spoiler anzeigen
  • Ja, Geschwindigkeit ist schon mal ein gutes Argument.

    Wie sieht es mit der Projektübersicht während des engineeren aus !?

    Scite hat ja keinen Projektexplorer, wie behaltet ihr da die Übersicht
    in umfangreicheren Anwendungen mit vielen Forms?

  • Hi!

    Hallo,
    das kann ich natürlich nicht auf AutoIt sitzen lassen :P

    Eines möchte ich gleich vorweg klarstellen:
    Ich mag AutoIt sehr und wollte es mit meinem Post sicher NICHT diskreditieren.

    Folgendes Programm liefert das Ergebnis für die Zahl 2147483647 in 0.05 Sekunden - und das auf meiner langsamen Kiste mit noch gefühlten 10 weiteren Anwendungen die laufen.

    Das mein "Algorithmus" extrem uneffektiv ist, ist mir auch klar. Man muss ja nur ungerade Zahlen und als Obergrenze für den Dividenden Wurzel n anstatt n nehmen (wobei es noch effektivere Algorithmen gibt).
    Aber mir ging es ja nicht darum, möglichst schnell eine Primzahl zu ermittlen, sondern möglichst viele Berechnungen anzustossen (als eine Art Benchmark).
    Wie ich schon sagte, ist die Funktion isPrime in beiden Sprachen identisch, und genau dadruch ist es ja erst möglich, einen Vergleich anzustellen.

  • AutoIt ist eine simple Programmiersprache, die relativ leicht zu erlernen ist und quasi die komplette Windows API benutzen kann. Ferner kann man in AutoIt zusätzlich noch Inline ASM betreiben oder selbst geschriebene DLLs einbinden, sodass die Grenzen fast grenzenlos sind.

    Die Grenzen sind somit i.d.R. das Wissen des Programmierers.

    Auch am Arsch geht ein Weg vorbei...

    ¯\_(ツ)_/¯

    • Offizieller Beitrag

    Scite hat ja keinen Projektexplorer

    Na, na - red dir nix übern Hals. ;)
    SciTE hat eine Projektverwaltung, wenn auch recht rudimentär. Du kannst alle momentan geöffneten Dateien unter einem Projektnamen speichern. Öffnest Du das Projekt, werden alle Tabs mit den Dateien wieder hergestellt.
    Im Allgemeinen ist das völlig ausreichend. Wenn Dir an SciTE irgendwas fehlen sollte, schau zuerst zu meinen SciTE-AddOns, wenn Du da nicht fündig wirst melde dich, für die meisten Probleme findet sich auch eine Lösung.

  • Durch die fehlende Ausführgeschwindigkeit zwingt die Sprache den Programmierer oft dazu effizient zu programmieren. Während man in C kein Problem hat, wenn z.B. nach dem Klick auf einen Button 100ms vergehen, wird man in AutoIt locker 10s warten müssen. Das ist Nach- und Vorteil zugleich, da man hier mit den eigenen Fehlern wesentlich stärker konfrontiert wird. Problematisch ist natürlich der (je nach Problem) unverhältnismäßig große Aufwand um die zu optimierende Funktion zu analysieren und zu verbessern. Wenn man das aber schon sehr oft getan hat bekommt man ein "Gefühl" dafür welche Wege schneller sind als andere, sodass man insgesamt ein besserer Programmierer wird und nicht mehr so lange für Optimierungen braucht.