Beiträge von Andy

**Andy**

Forensuche mal bemüht?
Memory allocating-error beim Id3 tag in ein Array schreiben

**Andy**

@UEZ und BugFix,
sehr interessant, dass bei euren Prozessoren FOR ca. 10x schneller ist, als die anderen Schleifen!
Ich vermute einfach mal ein "passendes" Flag beim Compilieren von AutoIt für diesen Prozessortyp. Wobei ich mich dann frage, was an einer WHILE 10x mehr Zeit verbraten soll?!
Kann genausogut sein, dass der Prozessor bei FOR durch irgendwelchen Code NICHT in den Schlafmodus geschickt wird, bei den anderen Schleifen aber schon.

Man sieht mal wieder deutlich die Hardware-Abhängigkeit, unabhängig von der Geschwindigkeit der verwendeten Prozessoren/Systeme.
Ich dreh schon durch, wenn ich diese "Speedtests" sehe, die bei 20% Prozessorlast laufen. Was wird denn da gemessen?

Vielleicht sollte man sich eher darauf konzentrieren eine UDF zu erstellen, welche bei zeitkritischen AutoIt-Scripten diese zwingt,
- auf einem Prozessorkern zu laufen (und damit den Turbo-Modus zu erzwingen)
- nicht durch das BS unterbrochen zu werden ( Priorität erhöhen)
- uswusf (Ideen erwünscht )
also erstmal die Hardware in einen definierten Zustand zu zwingen was ca. 200-300% Geschwindigkeitszuwachs bringt, bevor man sich Gedanken über Optimierungen innerhalb der Software macht, welche gerade mal 20-30% schnellere Ergebnisse erzielt!
Im Batteriebetrieb bei Notebooks kann man ja (automatisch) diese Funktionen abschalten, bzw. per User-Interaktion auswählbar machen.

Ich vermute, dasss gerade die aktuellen "Super-Duper-Stromspar-Prozessoren" egal von welchem Hersteller vom BS auf lange Akkulaufzeit gezwungen werden (ansonsten machen diese Dinger auch überhaupt keinen Sinn! )
Daraus resultiert dann natürlich, dass so wenig Leistung wie möglich abgefragt wird. Wenig Leistung = geringe Geschwindigkeit...
Was diesen Thread dann auch ad absurdum führt!

**Andy**

Zitat von BlutigerAnfänger

Das Handbuch gibt hier nicht sehr viel her! man kann dort auch nicht suchen!

Doch, man kann....

Zitat von BlutigerAnfänger

Hat jemand die Geduld mir das zu erklären.

Abber sischääär
In der deutschen Hilfe findest du alles nötige, incl. lauffähiger Beispielscripte.

In Scite den Cursor auf den Suchbegriff stellen und F1 drücken lädt die Hilfe mit dem entsprechenden Eintrag!
Innerhalb der Hilfe gibt es den Reiter "Suchen".
Wenn du den genauen Suchbegriff bzw. Funktionsnamen kennst, einfach ins Suchfeld eingeben.
Unter der Themenliste die entsprechenden Häkchen setzen, damit kann man die Ergebnisse einschränken.
Wenn man "unscharf" suchen möchte, vor und hinter den Suchbeggriff ein Sternchen * eingeben!
Also *call* findet dann ALLE Wörter mit CALL in jedem Hilfethema! Mit den Häkchen unter der Themenliste kann man dann entsprechend einschränken/erweitern.

Innerhalb des Scriptes gibt es ausreichende Debugging-Funktionen, im Link in meiner Signatur ist Debugging ausführlichst beschrieben.
In Scite im Reiter "Extras" sind Debug-Kurzwahlen enthalten.
Cursor auf die Variable, deren Inhalt du wissen willst, ALT-d oder CTRL-SHIFT-d schreibt dann entweder eine Console- oder Msgbox-Debug-Zeile ins Script.

**Andy**

Sodele,
habe mal bissl rumgespielt mit den P-Stats meines (Laptop-) Prozessors.
Ich habe den überwiegenden Modus P6 (alles schläft, d.h. überwiegende Nutzung von Browser, Textverarbeitung, RDP usw) underclocked und massiv undervolted.
Schon ab P5 ist aber die maximale Taktfrequenz für alle Cores eingestellt!
Dadurch beschleunigt sich der Testlauf auf nahezu die dreifache Geschwindigkeit! vgl- oben.

Spoiler anzeigen

Code

>CPU: AMD A6-3400M APU with Radeon(tm) HD Graphics X64
>RAM: 1.29/3.48 GB
>OS: WIN_7 (7601) X64
>Parameter: 100
+Func For (1)    needs for 4095 runs 424.79 ms (Average: 0.1037 ms)    --> 1.0x
-Func While (2)    needs for 4095 runs 684.54 ms (Average: 0.1672 ms)    --> 1.6x
!Func Do (3)    needs for 4095 runs 690.04 ms (Average: 0.1685 ms)    --> 1.6x

Für 08/15-AutoItscripte bringt das den nötigen "Druck", allerdings sei erwähnt, dass solche "Optimierungen" nur sinnvoll sind, wenn man weiß, was man tut!
Übrigens verkürzt sich die Batterielaufzeit im Akkubetrieb nicht, wenn nicht gerade Games gezockt, oder andere prozessorlastige Anwendungen laufen...

//EDIT
Um nochmal klarzustellen:
Es wurde NICHTS übertaktet oder an der Hardware gepfriemelt, lediglich der voreingestellte "Schlafmodus" des Prozessors wurde per SOFTWARE angepasst!

**Andy**

Hi,

ich rate dir DRINGEND, sämtliche Funktionen deiner (nicht nur der mir bekannten ) Projekte in Verbindung mit den neueren AutoIt-Versionen zu überprüfen, sowohl auf die allgemeine Funktion, als auch auf die Ergebnisse!
Ich habe die 3.3.8.1 in Produktivumgebung laufen, und habe damit bisher noch keinerlei Probleme oder gar Einschränkungen festgestellt.

Solltest du trotzdem eine der neueren Versionen in Erwägung ziehen, würde ich diese komplett auf einer eigenen Maschine/Account neu installieren. Keinesfalls über die "alte" 3.3.8.1-Version "drüberbügeln"!
Dann kannst du gefahrlos die neueren AutoIt-Versionen mit deinen Projekten testen und im Bedarfsfall wieder auf DEINE 3.3.8.1 zurückgreifen!

**Andy**

Das Problem tat schon IMMER (!) bei grafischen Systemen auf.
Bei Textformaten (80x25) war übrigens nicht die eigentliche Position und Größe des "Controls" das Problem, sondern die in den verschiedenen Schriftarten implementierten Grafikzeichen....
Daher ist es sinnvoll, wie vom TE gepostet, die unterschiedlichen optischen Eindrücke zu vergleichen und ggf. anzupassen. Eine Einstellung "lass mein GUI unabhängig von den Systemeinstellungen immer gleich aussehen" gibt es nicht.

Wer sich darüber beschwert, sollte sich mal ernsthaft fragen, woher das Elend eigentlich kommt!
Wenn von der überwiegenden User- und Entwicklerschaft dem heutzutage immer fortgeschritteneren Klickibunti ein weitaus höherer Stellenwert beigemessen wird als Usability und Fehlerfreiheit, braucht sich niemand zu wundern!

Alternativ bastelt man sich die GUI statt aus Controls selbst aus Bildern zusammen, die kann man pixelgenau positionieren. Bissl mehr Aufwand, aber dafür von den nächsten erscheinenden Systemen unabhängig^^

**Andy**

Why don´t you get the solution from >>HERE<< ?

**Andy**

Hi,
schau mal beim User water in die Signatur, dort ist ein Link für die "neue" Excel-UDF!

Ausserdem habe ich festgestellt, dass eine SQL-Datenbankabfrage auf ein Excel-File
1. sauschnell
2. flexibel
ist, und
3. bei Bedarf auch alle Daten in einem Array zurückgibt!

**Andy**

Hi,
wenn du eine Batch in ein AutoItscript überführen willst, wäre es sinnvoll, diese Batchdatei zu zeigen statt deines nicht funktionierenden AutoIt-Codes!

Zitat von djdanby

. Und damit niemand die Daten ausliest hatte ich es bisher immer in eine Exe kompiliert.

Sowohl aus der Batch-compilierten Exe als auch der AutoIt-Exe kann jeder Anfänger bei Bedarf den Quellcode auslesen!

Zitat von Lottich

Leider gibts keine "aktuelle" deutsche Hilfe, aber Englisch sollte ja nicht wirklich ein Problem sein

Wenn du meinst, dass die deutsche Hilfe nicht aktuell ist, dann beschreibe das mal näher!
Ich benutze täglich die deutsche Hilfe, bisher habe ich noch keine Funktion gefunden, die dort nicht behandelt ist!

**Andy**

Spoiler anzeigen

Code

>Result with AutoIt 3.3.10.2 x86.
>CPU: AMD A6-3400M APU with Radeon(tm) HD Graphics X64
>RAM: 1.60/3.48 GB
>OS: WIN_7 (7601) X64
>Parameter: 100
+Func For (1)    needs for 4095 runs 2000.94 ms (Average: 0.4886 ms)    --> 1.0x
-Func While (2)    needs for 4095 runs 2457.75 ms (Average: 0.6002 ms)    --> 1.2x
!Func Do (3)    needs for 4095 runs 2867.37 ms (Average: 0.7002 ms)    --> 1.4x


>Result with AutoIt 3.3.10.2 x86.
>CPU: AMD A6-3400M APU with Radeon(tm) HD Graphics X64
>RAM: 1.55/3.48 GB
>OS: WIN_7 (7601) X64
>Parameter: 100
+Func For (1)    needs for 4095 runs 1881.05 ms (Average: 0.4594 ms)    --> 1.0x
-Func While (2)    needs for 4095 runs 3042.34 ms (Average: 0.7429 ms)    --> 1.6x
!Func Do (3)    needs for 4095 runs 3061.27 ms (Average: 0.7476 ms)    --> 1.6x




>Result with AutoIt 3.3.10.2 x64.
>CPU: AMD A6-3400M APU with Radeon(tm) HD Graphics X64
>RAM: 1.55/3.48 GB
>OS: WIN_7 (7601) X64
>Parameter: 100
+Func For (1)    needs for 4095 runs 1285.12 ms (Average: 0.3138 ms)    --> 1.0x
!Func While (2)    needs for 4095 runs 1945.69 ms (Average: 0.4751 ms)    --> 1.5x
-Func Do (3)    needs for 4095 runs 1903.94 ms (Average: 0.4649 ms)    --> 1.5x




>Result with AutoIt 3.3.10.2 x64.
>CPU: AMD A6-3400M APU with Radeon(tm) HD Graphics X64
>RAM: 1.55/3.48 GB
>OS: WIN_7 (7601) X64
>Parameter: 100
+Func For (1)    needs for 4095 runs 1224.09 ms (Average: 0.2989 ms)    --> 1.0x
-Func While (2)    needs for 4095 runs 1900.80 ms (Average: 0.4642 ms)    --> 1.6x
!Func Do (3)    needs for 4095 runs 2113.18 ms (Average: 0.5160 ms)    --> 1.7x

Alles anzeigen

Wie man deutlich sieht, weichen die Ergebnisse der einzelnen "Tests" voneinander ab, obwohl diese direkt hintereinander durchgeführt wurden!
DAS ist das eigentliche Problem bei AutoIt-Scripten!
Wie soll man etwas profilen und nach Geschwindigkeit optimieren, wenn Laufzeitunterschiede von +-20-30% völlig normal sind?!
Windows an sich funkt derart oft dazwischen, da bekommt ein Interpreter echte Probleme und öfter mal den Boden unter den Füssen weggezogen.
Selbst während der Laufzeit dieser Tests werden Prozessorcores in den Tiefschlaf versetzt .

**Andy**

Zitat von AspirinJunkie

Optimierung auf paralleler Ebene ist eben nochmal ein ganz anderer Schuh.

wohl wahr...
Das ist auch mit ein Grund, wieso diese Technik, obwohl seit Urzeiten ( >20 Jahren ) möglich, kaum verwendet wird! Es ist nämlich eine große Portion KnowHow und Skill vonnöten...
Ich behaupte einfach mal, dass 99% der "Programmierer" schon mit dem Setzen der "richtigen" Compilerflags völlig überfordert sind, bzw. diese Art der Optimierung überhaupt nicht verstehen und auch nicht für nötig halten!
Absolut gesehen rennt die "richtige" Programmierung und Anwendung der in Software verwendbaren möglichen Technik der Hardwareentwicklung 10 Jahre hinterher.
Wieso ein Programm beschleunigen, wenn man für einige Hunderter einen Rechner kaufen kann, der bis auf eine Handvoll Hardcore-Spiele sowieso jegliches Programm schon im Schlafzustand des Prozessorss mit völlig ausreichender Geschwindigkeit ausführt?!
Ich rede hier nicht von Forschungseinrichtungen und Hochschulen, welche dankbar sind für jedes kleine Quentchen Hardware-Power. DORT kostet Rechenpower richtig Geld, und genau dort wird bis auf den letzten Prozessortakt Software optimiert. Genau dort finden sich aber auch die Leute mit dem Skill und von dort kommen auch die hochoptimierten Bibliotheken

**Andy**

Zitat von Tobi

Ich versuche nun schon seit zwei Tagen deinen FTP-Uploader in Gang zu kriegen.

hmmmmm.....

Zitat von Tobi

"C:\Users\User\Desktop\ARBEITSORDNER\Uploader\FTP_Ex.au3" (10) : ==> Can not redeclare a constant.:
Global Const $GENERIC_READ = 0x80000000
Global Const ^ ERROR

Du weißt, was dort steht?!
Es soll eine bereits zugewiesene Konstante deklariert werden...irgendwo VORHER im Script wurde diese Konstante deklariert, also könnte man diese Zeile einfach löschen.

Jetzt stellt sich die Frage, WO diese Konstante bereits deklariert wurde.
#include ist in diesem Fall kontraproduktiv, einfach die Inhalte aller inkludierter Scripte in das Hauptscript kopieren, fertig.
Da in den inkludierten Scripten wiederum weitere Scripte inkludiert sind, findet sich der "Schuldige" sehr schnell.
Das dauert allenfalls 2 Minuten und nicht 2 Tage, man braucht keine "andere" AutoItversionen zu installieren, nur um EIN Script lauffähig zu machen uswusf.

Es stellt sich übrigens die Frage, wieso ein Compiler/Interpreter deklarierte Konstanten mit identischen Inhalten nicht als "Warnung" rauswirft, sondern als Fehler....

**Andy**

Zitat von Lottich

warum kann man bei SetError() eigentlich keinen Text angeben??? Das würde die Fehlerauswertung doch weeeeesentlich vereinfachen?

Wie kommt man überhaupt zu solch einer Frage?
1. Teil:

Zitat

warum kann man bei SetError() eigentlich keinen Text angeben???

ist eine Behauptung, die folglich irgedwoher kommen muss! Entweder durch eigene Versuche/Tests, oder durch lesen der Funktionsbeschreibung in der Hilfe/ Forenbeiträgen.
BEIDES (!) hat offensichtlich NICHT stattgefunden (davon steht jedenfalls nichts im Post), daher frage ich mich, wie man zu solchen Behauptungen kommen kann?!

2.Teil:

Zitat

Das würde die Fehlerauswertung doch weeeeesentlich vereinfachen?

(deine e-Taste prellt) zeigt, dass du bisher weder Error-Codes in internen Funktionen, noch in UDF´s ausgewertet hast! Denn dann hättest du seit 3 1/2 Jahren Forenzugehörigkeit feststellen müssen, dass (s. Bugfixens Post) diese Art der Errorbehandlung zumindest machbar ist! Einfaches ausprobieren hätte auch geholfen....

**Andy**

Zitat von Make-Grafik

Natürlich sollte man zuerst den Algorithmus an sich verbessern. Wie kommt man eigentlich darauf? Bzw. wo gibt es Lektüre zu diesem Thema? Gibt's da spezielle Begriffe zu um sich das eine oder andere selber zu googeln?

Die erste Regel ist, den Code zu profilen!
In AutoIt haben wir dahingehend etwas gelitten, mehr wie einige Timings bekommt man nicht aus dem ausgeführten Code heraus...
In anderen Programmiersprachen gibt es Profiling-Tools, welche Ergebnisse bis zum Erbrechen (Anzahl Prozessortakte) bereitstellen!
Dabei sollte man beachten, dass es nichts nutzt, denjenigen Programmteil zu optimieren, der nur 5% der Gesamtlaufzeit beansprucht!
Also so die Timings setzen, dass man den Codeteil findet, welcher am öftesten/meisten angesprungen wird!

Die ersten Schritte wurden ja schon in den Beispielscripten gezeigt. Loop/Funktion ausstoppen, schneller = besser. Fertig!
Aber wie kommt man zu einem "schnelleren" Algorithmus? Naja, kurz gesagt wurde so gut wie jedes EDV-technische Problem schon bis zum Abwinken behandelt
Entweder man benutzt hochoptimierte Bibliotheken, oder man sucht in den einschlägigen Foren oder Webseiten <<LINK>>
Aber auch einfaches analysieren bringt oft schon erstaunliche Ergebnisse.
- Ist der Code zu parallelisieren, kann man ihn in mehrere "Threads" aufteilen?
- Gibt es mathematische Umformungen, um Berechnungen "anders" durchzuführen?
- Muss jede Funktion (UDF) unbedingt mit sämtlichen Errorhandlings ausgestattet sein?
- Habe ich den Vergleich zum unoptimierten Code? Wie viel schneller ist der optimierte Code?
- Wie viel schneller sind vergleichbare Programme? Lohnt es sich, Stunden/Tage/Wochen aufzuwenden um in einem Programm welches 2x am Tag läuft, 10 Sekunden einzusparen?

Und man sollte sich fragen, wieso ein Prozessor, welcher heutzutage mit >4 Cores und 4,5Ghz Takt daherkommt, per "Sleeps" dahin gebracht wird, mit 1-2% Last zu laufen...
Mir ist ehrlich gesagt lieber, der Prozessor hat so viel zu tun, dass mein Profiling-Tool kein einziges Mal den Tiefschlaf registriert! Erst wenn das Ding richtig glüht, wird es auch ausgenutzt! Einen Ferrari kauft man auch nicht, um 3x im Jahr im 2. Gang zum Einkaufen zu fahren....
GuiGetMsg() ist so ein Kandidat, der in einer geschwindigkeitsoptimierten Schleife NICHTS zu suchen hat!

**Andy**

Zitat von GtaSpider

Klar beim If/Switch Fall ist es relativ egal, man sieht ja das bei einem Aufruf der unterschied bei 0,002 ms ist, aber z.B. die Geschichte mit der For/While Schleife war hier sehr hilfreich und wenn ich nun 50 Interpretationsfunktionen habe, in denen ich alle von While auf For wechsle sind das gut und gerne paar Millisekunden die man direkt merkt.

Genau DAS meine ich mit dem finden des "inner loop"!
Wenn ich Millisekunden schinden will/muss, dann kommt die Schleife natürlich mit in die entweder per DllCall() / DllCallAddress() angesprochene Funktion!
Es bleibt auszuprobieren, ob der overhead von DllCall() / DllCallAddress() nicht den Gewinn über die schnellere Ausführungszeit auffrisst!

Zitat von GtaSpider

Das habe ich nur geschafft in dem ich an jeder Kleinigkeit herum experimentiert habe um es so effizient wie nur möglich zu gestalten, da hier wirklich sehr viel interpretiert wird.

Ein langsam programmiertes Programm bzw. Algorithmus bleibt auch langsam, wenn man es auf einem schnellen Rechner oder mit einem schnellen Compiler einsetzt.
Wenn man, so wie du es gemacht hast, den Algorihmus bzw. den Programmablauf ständig mit Hinblick auf Geschwindigkeit optimiert, ist man schon auf dem richtigen Weg.
Ich habe allerdings die Erfahrung gemacht, dass sich kaum jemand diese Mühe macht....intensives profiling ist auch nicht jedermanns Sache!

Ich behaupte mal, dass AutoIt idR. schnell genug ist, gerade im Hinblick auf

Zitat von GtaSpider

eine schnelle Benutzeroberfläche, wenn man es richtig angeht.

Die Frage bleibt, ob man, wenn man wirklich bis auf die letzte Rille optimieren muss, nicht einfach nur die GUI und das drumherum in AutoIt programmiert, und den (idR wenigen) zeitintensiven Rest dann "auslagert".

**Andy**

so?

Spoiler anzeigen

[autoit]

#include <Array.au3>
$inhalt = FileRead("paarungen.csv")