Beiträge von chesstiger

Zur "ersten" Lösungsvariante von Musashi... Ich würde mal behaupten, dass das mit RegEx in AutoIt nicht eleganter zu lösen ist.

AutoIt unterstützt leider keine Case Conversion bei RegExpReplace. Warum auch immer, PCRE kann das eigentlich.

Wenn das so wäre, könnte man das mit nem recht einfachen Pattern lösen:

Pattern: \h*(?:(?:([a-z][A-Z]+))|(?:([A-Z])([A-Z]*)))(\h*)

Replace: \L$1\U$2\L$3$4

Beispiel bei RegEx101

Zur Datenbank... Das wird aber relativ aufwendig, wenn auch Markennamen davon erkannt werden sollen. Oder?

So viel zum Wochenende...

Punkt 2 und 3 habe ich gerade umgesetzt.

Allerdings scheint nach ein paar Jahren der Update-Mechanismus nicht mehr so ganz so gut zu funktionieren. Hab's daher mal im ersten Beitrag neu verlinkt.

Von den CHM-Dateien hab ich nie so viel gehalten. Da finde ich HTMLs wesentlich universeller und besser zu handhaben.

Ein nettes Feature wäre es noch, automatisch auch eine CallTip-Datei zu generieren.

Ich weiß nicht, warum, aber dieser Thread hier ist irgendwie völlig an mir vorbei gegangen...

water

Eins nach dem anderen:

Punkt 1:

Das Problem, was du vor einer halben Ewigkeit beschrieben hast... Was soll ich sagen? It's not a bug, it's a feature.

Mein Programm erkennt optionale Parameter und vermerkt dies auch in der Beschreibung. Einmal wird hinter dem Parametername "optional" vermerkt, und die entsprechenden Zeilen bekommen per CSS ein etwas abweichendes Aussehen. Außerdem werden beim Parsen für den "gelben Kasten" die Func-Zeilen verwendet, die ja die eckigen Klammern gar nicht enthalten. Da ist ja dann eigentlich durch den Default-Wert sofort erkennbar, dass die Angabe optional ist. War also tatsächlich eher eine Design-Entscheidung, als ein Problem. Aber der Aufwand, das als optionalen Switch in das Programm einzubinden, sollte sich in Grenzen halten.

Punkt 2:

Klar, das macht völlig Sinn, wenn man die Software in einen bestehenden Build-Prozess einbinden möchte. Stimme ich dir zu, setze ich um. Ist ja kein großer Aufwand.

Punkt 3:

Ja, das macht eigentlich auch mehr Sinn. Die gewählte Reihenfolge war eher nach Gefühl, aber so entspricht es ja ungefähr der logischen Reihenfolge. Hab da schon ein Bild vor Augen, wie sich das optisch macht.

Punkt 4:

Related gibt es doch. In dem Block werden sogar automatisch Sprunglinks zu den jeweiligen Funktionen gesetzt.

Ich würde mal vom Gefühl her sagen, dass ich am Wochenende wohl mal nen Stündchen dafür aufbringen kann.

Und du wirst lachen, es ist quasi deine Schuld, dass ich gerade wieder auf diesen Thread gekommen bin. Hab grade auf einem Rechner die AD.au3 runtergeladen und dabei dann registriert, dass da ja eine Doku im HTML-Format bei ist. Und dachte noch so "Ach, schau mal, sowas hast du doch auch mal programmiert".

Ohje. Hatte das hier völlig verdrängt, bin gerade selber darüber gestolpert... Ist nun im Startpost verlinkt.

autoBert

Ja, das geht grundsätzlich auch mit dem in Windows 10 integriertem PDF-Drucker.

Man muss dann allerdings erstens ein Programm haben, was das HTML-Dokument an den Druckertreiber weitergibt... Also z.B. IE oder Chrome. Die wiederum müssten dann im Hintergrund entsprechend aufgerufen werden, was mit dem IE noch geht, mit Chrome aber schon eine Gratwanderung wird.

Und zweitens erzeugt der integrierte PDF-Drucker nur ganz primitive PDF-Dokumente, in denen bspw. Text nicht als Text abgelegt ist, sondern als Bitmap. Das führt dazu, dass der Benutzer keine einzelnen Elemente aus dem PDF-Dokument rauskopieren kann. Wir bereiten mit wkhtmltopdf ziemlich viele Listen und Tabellen auf, die wir an unsere Kunden rausschicken. Da soll der Kunde natürlich schon die Möglichkeit haben, auch Preise und Artikelbezeichnungen aus dem Dokument zu kopieren.

Ich habe damals auch viel damit rumexperimentiert, bin dann aber doch bei wkhtmltopdf geblieben, weil es deutlich flexibler ist und auch noch portabel.

Das hier ist zum Beispiel unser Ordersatz: https://3f-berleburg.de/download/Ordersatz.pdf

Diese Datei wurde aus einer primitiven CSV-Datei automatisch mittels eines AutoIt-Skripts und wkhtmltopdf generiert. Besondere "Higlights", die nur mit wkhtmltopdf möglich sind... Das anklickbare Inhaltsverzeichnis mit Sprüngen zu den entsprechenden Abschnitten, die immerwiederkehrende Kopfzeile auf jeder Seite, die _nicht_ Bestandteil der ursprünglichen HTML-Datei ist usw...

Kurzum: Für ganz ganz simple Sachen reicht auch der integrierte PDF-Drucker. Aber für alles weitere ist wkhtmltopdf echt ein super Alleskönner.

Ich habe mir angewöhnt, für sowas wkhtmltopdf zu verwenden. Damit kann man aus einer HTML-Datei eine entsprechende PDF-Datei erzeugen. Sämtliche Berichtsaufbereitung bei uns in der Firma funktioniert damit. Der Vorteil ist, dass man super Templates nutzen kann und ansonsten nur ein wenig HTML/CSS beherrschen muss.

Dass du das nur im aktuellen Kontext setzen musst, hab ich doch in dem Vorgängerthread schon gesagt.

RE: Installation mehrerer SciTE-Versionen

Hab grad mal rumprobiert und Doku gelesen: Es gibt eine Windows-Systemvariable mit Namen SCITE_USERHOME.

Wenn du die im selben Kontext vor dem Aufruf der SciTE-Executable überschreibst, solltest du eine andere SciTEUser.properties erzwingen können. Beispielsweise so:

ECHO OFF
ECHO %SCITE_USERHOME%
SET SCITE_USERHOME=%APPDATA%\..\Local\SciTE_ohne_AutoIt
ECHO %SCITE_USERHOME%
"C:\Program Files (x86)\AutoIt3\SciTE\SciTE.exe"

Du könntest einfach mit FileExist prüfen, ob die Datei existiert, und dann ggf. selber eine Fehlermeldung ausgeben und gar nicht erst ShellExecute aufrufen.

Scheint ja wirklich irgendeine Firebird-Eigenart zu sein.

MS SQL und MySQL würden sich nicht so verhalten. Kannst du das ganze vielleicht mit einem GROUP BY "austricksen"? Mir würde da bspw. die Gruppierung nach dem Feld HERSTSERNUM einfallen.

Zitat von Musashi

Gruß Musashi

P.S. : Es gibt im engl. Forum einen User namens Chesstiger - bist Du das ? Falls ja, editiere ich meinen Beitrag dort, sodass die Meriten an die richtige Adresse gehen .

@Musashi Yes, das bin ich. Trete da aber nicht wirklich in Erscheinung. Da ist mir die deutsche Community lieber.

Aber schön, dass Jon mit Zugriff auf den Sourcecode zum selben Ergebnis kommt wie ich mit externen Tools.

Ansonsten gebe ich euch recht. Es wäre wirklich cool, wenn wir am Core mitarbeiten könnten. Im Endeffekt ist das zwar Jons gutes Recht - aber ich glaube, wir würden alle davon profitieren.

Zitat von Professor Bernd

Könnt ihr mal alle Nachteile für a3x Dateien nennen?

Dazu müsste man erstmal wissen, was denn a3x-Dateien überhaupt sind. Zitat aus der Hilfe:

Zitat

Compiling Scripts with Aut2Exe
Note: Scripts can be compiled with .a3x extension. They should be run with AutoIt.exe filename.a3x. The .a3x contains the script itself with all referred #include plus the FileInstall files. This format allows you to distribute smaller files as they don't include the AutoIt3.exe in each compiled script. You still need to have it accessible on the target machine but just AutoIt3.exe.

Kurz zusammengefasst: Eine a3x-Datei enthält das Originalskript, alle Inludes und alle per FileInstall eingebundenen Dateien. Im Gegensatz zur exe-Datei fehlt hier aber der AutoIt-Interpreter (AutoIt3.exe). Der Interpreter muss also auf dem Zielsystem vorhanden sein.

An Nachteilen bei deinem Anwendungsfall fällt mir da gerade ein... Nehmen wir an, Du schreibst Deine ganzen Skripte für den Editor unter AutoIt 3.3.14.5. Du erzeugst dann die entsprechende a3x-Datei, von den Includes her passt alles. Jetzt führe ich diese a3x-Datei auf meinem System aus - dummerweise habe ich AutoIt nach der Erstinstallation aber nie aktualisiert, also läuft bei mir alles mit 3.3.8.1. Du benutzt jetzt in deinem Skript aber Sprachfeatures (ich meine keine UDFs!), die aus neueren AutoIt-Versionen stammen. Eine kleine Auswahl dieser Fallstricke: Ternärer Operator, leere Arrays, Direktzugriff auf Indizes von Array-Ausdrücken (sowas: StringSplit(...)[0]), das Keyword Null, ObjGet mit Instanz-Angabe... Und dann gibt es Bruch. Denn meine "alte" AutoIt3.exe kann dein neues a3x-Skript nicht ausführen. Vermutlich würde das ganze einfach mit einem Syntax Error abschmieren.

Ich schließe mich der Meinung der anderen an dieser Stelle an... Unterstütz einfach nur die aktuellste AutoIt-Version. Es gibt (fast*) keinen Grund, eine alte Version von AutoIt zu verwenden. Im Gegenteil: Solche Sachen wie der haarsträubende Hex-Fehler sind ein guter Grund, immer die aktuellste Variante zu nehmen.

* PluginOpen war schon cool...

Zitat von chesstiger

Erster Durchlauf 16,219 Sekunden, zweiter Durchlauf 17,092 Sekunden. Das Phänomen ist also deutlich deutlich abgeschwächt, wenn nicht sogar verschwunden. Das kann eigentlich nur damit zusammenhängen, dass PeekMessageW mit Monitoring deutlich länger zum Ausführen braucht.

Tja, beim nochmal lesen kommen einem schon mal Ideen... Nach ein paar Stunden hab ich den Wald vor lauter Bäumen nicht mehr gesehen. Das hat rein gar nichts mit dem beobachteten Phänomen zutun. PeekMessageW wird durch die Monitoring-Software quasi um eine konstante Zeit verlangsamt. Bei 1.000.000 Aufrufen lässt das den relativen, prozentualen Unterschied der beiden Messwerte natürlich erheblich schrumpfen. Aber der absolute Unterschied ist ja immernoch bei rund 0,85 Sekunden. Das ist in der selben Größenordnung wie die Differenz im ersten Durchgang. Von daher: Vergesst diesen Absatz. Die WinAPI-Aufrufe haben nichts mit der Verzögerung zutun, das ist rein AutoIt-Intern.

Und danke für das Lob. Das ist wirklich ein spannendes Thema.

Mars Die Error-Checks klingen gar nicht so unplausibel. Der nächste Schritt wäre jetzt, mit einem Tool wie IDA an die Sache ranzugehen und zu schauen, welche AutoIt-Internen Funktionen nach dem Erstellen einer GUI länger zum Ausführen brauchen.

Edit: Es hat mir einfach keine Ruhe gelassen! Es gibt von Intel ein Tool namens VTune. Damit kann man super maschinennahe x86-Anwendungen profilen, d.h. hinsichtlich Geschwindigkeit optimieren. Der API-Monitor ist zwar cool, aber die Intel-Software liefert definitiv die besseren und verlässlicheren Daten. VTune ist dann in der Lage, genau aufzulisten, wie viel CPU-Zeit in welcher Funktion draufgegangen ist. Ohne den passenden Quellcode zur Binärdatei geht das leider nur eingeschränkt... Aber es geht. Ich habe also folgendes Programm kompiliert und mit VTune ausgeführt:

$bWithGui = False
If UBound($CmdLine) >= 2 Then
$bWithGui = True
EndIf


If $bWithGui Then
$hWnd = GUICreate("BetweenCalcs")
GUISetState(@SW_SHOW)
GUIDelete()
EndIf


$nTime = _Calc()


If $bWithGui Then
FileWrite("log.txt", StringFormat("%02d:%02d:%02d> %s: %.3f ms" & @CRLF, @HOUR, @MIN, @SEC, "MIT Fenster", $nTime))
Else
FileWrite("log.txt", StringFormat("%02d:%02d:%02d> %s: %.3f ms" & @CRLF, @HOUR, @MIN, @SEC, "OHNE Fenster", $nTime))
EndIf


Func _Calc()
Local $iTime, $iValue = 0
$iTime = TimerInit()
For $i = 1 to 5000000
$iValue += 1
Next
$iTime = TimerDiff($iTime)
Return $iTime
EndFunc   ;==>_Calc

Es ist also ein Programm, welches je nach Übergabe eines Kommandozeilenarguments vorher ein Fenster erstellt oder eben nicht. Das von AutoIt gemessene Ergebnis landet dann in einer Logdatei.

VTune kennt mehrere Möglichkeiten, eine Anwendung zu profilen. Ich habe mich für die Detaillierteste entschieden, welche aber auch den meisten Overhead produziert: Auf Hardware-Basis, mit Stack-Verfolgung. Im Rahmen dieses Profilings hat die AutoIt-Anwendung selber folgende Zeiten ausgegeben:

01:26:08> OHNE Fenster: 2262.843 ms
01:26:53> MIT Fenster: 7075.408 ms

Nicht ganz der Faktor 10, wie er sonst auf meiner Hardware auftritt, aber dennoch ist das Phänomen definitiv erkennbar.

VTune misst zunächst mal grob die gesamte Ausführungszeit (also CPU + Idle) und dazu dann noch die gesamte CPU-Zeit:

Nun, hier erkennt man nicht nur, dass die Variante ohne Fenster nicht nur deutlich schneller ist, sondern auch offensichtlich wesentlich weniger Zeit im Idle "verschwendet". Aber natürlich ist auch die CPU-Zeit sehr interessant. Wir sprechen hier von einer Differenz von 2,7 Sekunden - nur für das Erstellen eines Fensters.

Und jetzt das Interessante: Die detaillierte Ausgabe von VTune. Man kann eleganterweise sogar zwei Durchgänge direkt in VTune vergleichen. Im sog. Bottum-Up findet man dann alle relevanten Funktionen aufgelistet (inkl. Herkunfts-Modul), zusammen mit der CPU-Zeit vom Prozess ohne Fenster, mit Fenster und mit der Differenz. Die komplette Tabelle ist als CSV im Anhang, hier möchte ich nur einen kurzen Ausschnitt anfügen, nämlich die zeitlich signifikantesten Funktionen.

Wer jetzt nicht selber rechnen mag: Die summierte Differenz entspricht 2,66 Sekunden - also quasi der kompletten Differenz der CPU-Zeiten der beiden Programmvarianten. Nun, was haben wir denn hier für Funktionen? Alle "func@..." aus dem Modul calltester3.exe (so heißt mein kompiliertes AutoIt-Programm) sind vermutlich interne AutoIt-Funktionen, die z.B. eine Skriptzeile interpretieren könnten, eine UDF aufrufen könnten... Was auch immer. Alle Funktionen, die zum Modul wow64cpu.dll gehören, sind vermutlich Teil der Win32-Abstraktionsschicht. Grundsätzlich arbeiten mittlerweile alle Windows-internen Funktionen als 64-bit Software. Damit vorhandene 32-bit Software weiterhin lauffähig bleibt, kommt diese Abstraktionsschicht zum Einsatz, die die 32-bit Funktionsaufrufe in 64-bit Funktionsaufrufe übersetzt. Und zu guter Letzt hätten wir unseren Hauptübeltäter: PeekMessageW aus der user32.dll. Wer's nicht weiß: Diese Funktion ist zum Verarbeiten von Thread- und Fenster-Nachrichten innerhalb der Win32-API. Das ist quasi die Funktion, die hinter AutoIts GUIGetMsg steht. Üblicherweise wird diese PeekMessage-Funktion immer und immer wieder in einer Schleife aufgerufen, um auf Interaktionen mit dem Fenster reagieren zu können.

Dieser Test ist auf demselben System durchgeführt worden, wie der zwei Posts davor, also mit Windows 10 1904. Das ganze werde ich morgen mal noch auf einer Windows 7 Maschine machen. Und ich wette damit, dass PeekMessageW dann nicht mehr so viel Zeit frisst.

Ins Blaue hineingeraten würde ich Mars' Begründung hier auch übernehmen. Irgendwas am Windows-Verhalten hat sich geändert, was die AutoIt-EXE dazu bringt, PeekMessageW unverhältnismäßig oft aufzurufen.

Also, ich habe jetzt in stundenlanger Kleinarbeit mal versucht, mittels eines API-Monitors (http://www.rohitab.com/apimonitor) herauszufinden, welcher Systemaufruf nach dem Erstellen eines Fensters länger dauert oder öfter auftritt. Ich habe dazu das folgende Testskript in kompilierter Form (x86) verwendet::

#include <WinAPI.au3>
$gs = ""


_ConsoleWrite("> ------------------------------------------" & @CRLF)
_ConsoleWrite("> >>>>> Check 1.1 - Calc() vor MsgBox <<<<< " & @CRLF)
FileWrite("BeforeCalcs", "")
_Calc() ; vor Aufruf einer MsgBox


$hWnd = GUICreate("BetweenCalcs")
GUISetState()
GUIDelete()
FileWrite("BetweenCalcs", "")


_ConsoleWrite("> >>>>> Check 1.2 - Calc() nach MsgBox <<<<<" & @CRLF)
_Calc() ; nach Aufruf einer MsgBox
_ConsoleWrite("> ------------------------------------------" & @CRLF)
FileWrite("AfterCalcs", "")
MsgBox(0, "AutoIt Calltester", $gs)


Func _Calc()
Local $iTime, $iValue = 0
$iTime = TimerInit()
For $i = 1 to 500000
$iValue += 1
Next
$iTime = TimerDiff($iTime)
_ConsoleWrite("! " & StringFormat("% 15s: %4.3f ms", "Elapsed time = ", $iTime) & @CRLF)
EndFunc   ;==>_Calc


Func _ConsoleWrite($s)
$gs &= $s
EndFunc

Das ist das bereits bekannte Testscript, leicht modifiziert. Die FileWrites stehen deshalb da, weil man die im API-Monitor recht schnell finden kann (CreateFileW mit dem Dateiname als erster Parameter).

Dabei habe ich ein paar recht interessante Erkenntnisse gewonnen. Vorneweg: Die Ursache für die Verlangsamung konnte ich leider nicht ausmachen, es waren nur "Indizien" zu finden.

Also, steigen wir mal ein. Das Experiment findet statt auf meinem Notebook mit einem i7-7700HQ und Windows 10 Buildnummer 18362 (Windows 10 1903). Mit dem eingangs erwähnten API-Monitor kann man während der Laufzeit eines Programmes herausfinden und protokollieren, welche Funktionen in welchen (System-)Bibliotheken aufgerufen werden. Netterweise zeigt diese Software nicht nur die Parameter der aufgerufenen Funktion sowie deren Rückgabewert an... Nein, auch die Dauer des Aufrufs (also quasi die Differenz der Zeiten von CALL und RET) wird ermittelt. Das funktioniert, indem die jeweiligen Funktionen durch eine DLL Injection durch "Zwischenfunktionen" ersetzt werden. Das hat jedoch den Nachteil, dass die entsprechenden Systemaufrufe deutlich länger zum Ausführen brauchen. Leider ist es quasi unmöglich, alle Systemaufrufe auf einmal zu protokollieren. Das Log wird schlichtweg zu groß und der API-Monitor macht das nicht mit.

Daher habe ich im ersten Durchgang ein paar Funktionen mittels der Exclude-Funktionalität des API-Monitors ausgeschlossen. Und zwar HeapAlloc, HeapFree und PeekMessageW sowie nahezu alle anderen GUI-Funktionen. Die GUI-Funktionen hatte ich vorher in Einzeltest schon als Ursache ausschließen können. Dieser Durchgang ist im Anhang als ODS-Datei (innerhalb des ZIP-Ordners) enthalten. Kurz dazu: Das erste Tabellenblatt enthält das gesamte Log vom Start der EXE bis hin zur Anzeige der MsgBox mit den Ergebnissen am Ende. Danach kommen nur noch Aufräum-Arbeiten von AutoIt. Farblich im Log markiert sind... In gelb die Aufrufe von CreateFileW und alles, was damit zusammenhängt. Und in rot der Aufruf von CreateWindowEx zwischen den beiden Berechnungsfunktionen sowie alles, was dazu gehört. Auf dem zweiten und dritten Tabellenblatt sieht man dann, was noch an API-Aufrufen bei den beiden Berechnungsdurchläufen übrigbleibt. Nicht sonderlich viel. Im ersten Durchlauf sind es rund 23 API-Aufrufe, im zweiten Durchlauf 61. Wobei beim zweiten Durchlauf der erste Teil noch zur "Zerstörung" des Fensters gehören könnte. Verglichen mit der riesigen Gesamtmenge an API-Aufrufen sind diese Zahlen allerdings so oder so nicht relevant. Das sieht man auch schön, wenn man die Aufrufzeiten mal addiert. Die 23 API-Aufrufe im ersten Durchlauf brauchten 0,0000181 Sekunden. Die 61 API-Aufrufe im zweiten Durchlauf brauchten 0,0000368 Sekunden. Wenn man mal das rausrechnet, was auch noch zur GUI gehören könnte, kommt das so ziemlich auf's selbe raus. Verglichen mit der Gesamtlaufzeit der beiden Durchläufe laut AutoIt (sieht man im Gesamtlog ganz unten) sind das ohnehin verschwindend geringe Zeiten. Dort brauchte der erste Durchlauf ca. 0,3 Sekunden, der zweite Durchlauf etwa 1 Sekunde. Das zu untersuchende Phänomen ist also definitiv vorhanden, allerdings kann ich einen Zusammenhang mit den untersuchten Systemaufrufen dadurch nahezu ausschließen. Das sollte dann auch die Theorie widerlegen, dass Microsoft da absichtlich ausbremst.

Im zweiten Durchgang schließlich wollte ich dann die bisher ausgeschlossenen Funktionen untersuchen, die sonst mehrere hunderttausend Male während eines Programmdurchlaufes ausgeführt werden: HeapAlloc, HeapFree und PeekMessageW. Ich habe also - um die Datenmenge überschaubar zu halten - nur die Funktionen CreateFileW, CreateWindowEx und PeekMessageW überwacht. Da das Log ob der schieren Größe (~900 MB) kaum noch in LibreOffice Calc zu verarbeiten war, habe ich nur mit den Zeilennummern gearbeitet. Sowohl vor als auch nach der Fenstererstellung wird PeekMessageW in etwa 1.000.000 mal aufgerufen. Also auch da keine Diskrepanz. Das Interessante an dieser Stelle ist jetzt aber, dass ich in diesem Durchlauf (größenordnungsmäßig reproduzierbar) die folgenden Zeiten gemessen durch AutoIt erhalten habe: Erster Durchlauf 16,219 Sekunden, zweiter Durchlauf 17,092 Sekunden. Das Phänomen ist also deutlich deutlich abgeschwächt, wenn nicht sogar verschwunden. Das kann eigentlich nur damit zusammenhängen, dass PeekMessageW mit Monitoring deutlich länger zum Ausführen braucht.

Nun, was gewinnen wir an Wissen daraus? Ich bin mir nicht ganz sicher, wie das Ergebnis zu deuten ist. Den ersten Durchlauf hätte ich so gedeutet, dass die "Bremse" AutoIt-Intern sein muss, da kein WinAPI-Aufruf signifikant länger dauert. Und mit AutoIt-Intern meine ich, dass weder eine WinAPI-Funktion langsamer ausgeführt wird als vorher, noch eine WinAPI-Funktion öfter aufgerufen wird als vorher.

Aber was ich mit dem Ergebnis des zweiten Durchgangs anfangen soll, weiß ich selber noch nicht so ganz...

Puh, das ist echt interessant. Ich teste Mars' Skript mal mit dem Kram, an den ich gerade über Remote Desktop drankomme...

01. Notebook (Windows 10)

Gewichtungsfaktor 0.85

= = = Test Results = = =
991.69 (100.00%)
131.94 (13.30%)
= = = System Info = = =
CPU Name:        Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
CPU Physical Cores:    4
CPU Logical Cores:    8
OS Version:        WIN_10
OS Build:        18362
OS Arch:        X64

02. Server 1 (Hyper-V, Windows Server 2019)

Gewichtungsfaktor 0.28

= = = Test Results = = =
1006.03 (100.00%)
387.00 (38.47%)
= = = System Info = = =
CPU Name:        AMD EPYC 7252 8-Core Processor
CPU Physical Cores:    1
CPU Logical Cores:    2
OS Version:        WIN_2016
OS Build:        17763
OS Arch:        X64

03. Server 1 (physikalisch, Windows Server 2019)

Gewichtungsfaktor 0.75

= = = Test Results = = =
1055.76 (100.00%)
268.10 (25.39%)
= = = System Info = = =
CPU Name:        AMD EPYC 7252 8-Core Processor
CPU Physical Cores:    8
CPU Logical Cores:    16
OS Version:        WIN_2016
OS Build:        17763
OS Arch:        X64

04. Server 2 (physikalisch, Windows Server 2012)

Gewichtungsfaktor 0.23

= = = Test Results = = =
996.25 (100.00%)
1014.38 (101.82%)
= = = System Info = = =
CPU Name:        Intel(R) Xeon(R) CPU E5-2609 0 @ 2.40GHz
CPU Physical Cores:    4
CPU Logical Cores:    4
OS Version:        WIN_2012
OS Build:        9200
OS Arch:        X64

05. Server 2 (Hyper-V, Windows Server 2016)

= = = Test Results = = =
1052.24 (100.00%)
1039.83 (98.82%)
= = = System Info = = =
CPU Name:        Intel(R) Xeon(R) CPU E5-2609 0 @ 2.40GHz
CPU Physical Cores:    2
CPU Logical Cores:    2
OS Version:        WIN_2016
OS Build:        14393
OS Arch:        X64

Ich mache im Laufe des Sonntags mal einen Abstecher in die Firma und teste mal auf verschiedenen Clients... Windows Server 2019 ist aber auf jeden Fall auch betroffen. Auffällig ist, dass mein Server mit AMD Epyc CPU extreme Schwankungen aufweist. Das zweite Testergebnis fällt immer irgendwo zwischen 25 und 50 Prozent, was - verglichen mit meinem Notebook - eine echt große Schwankung ist. Dennoch scheint die AMD-CPU nicht ganz so stark davon betroffen zu sein (Faktor 2-4 verglichen mit Faktor 8 bei Intel). Edit: Bei den beiden Maschinen mit Windows Server 2019 möchte ich kurz auf die Build-Nummer hinweisen. Das ist die LTS-Variante von Server 2019, welche auf Windows 10 1809 basiert. Wenn es ein grundsätzliches Problem in Windows 10 ist, kann das also nicht erst mit 1904 oder 1909 aufgetreten sein.

Das ist echt spannend.

Zitat von BugFix

Das ist für eine Interpretersprache nicht realisierbar.

Na, da muss ich aber mal kurz widersprechen. Warum sollte das nicht realisierbar sein? Das ist jetzt zwar ein bisschen OT, aber grundsätzlich ist das natürlich möglich. Eine Interpretersprache geht ja im Endeffekt das Programm auch nur Schritt für Schritt durch, genau wie ein Hardware-Prozessor den Maschinencode. Und auch eine Interpretersprache könnte nach jedem Schritt den aktuellen Status des Programmes (Speicherinhalt, Program Counter usw.) zur Verfügung stellen, sodass man ihn mit einer interaktiven Befehlszeile (Debugger) auswerten kann. AutoIt kann das nicht, da hast du völlig recht. Aber die Spracharchitektur im Sinne einer Interpretersprache ist nicht der technische Grund dafür.

Man müsste vielleicht mal in den Sourcecode der letzten Open Source AutoIt-Version gucken. Wenn wir uns mal kurz auf die reine technische Realisierbarkeit beschränken und jegliche juristischen/lizenzrechtlichen Hindernisse ignorieren... Soweit ich weiß, wird in den meisten Interpretersprachen auch eine Art Baumstruktur des Skriptes erzeugt, ähnlich wie beim Kompilieren bei einer Compiler-Sprache (Google-Stichwörter Lex und Yacc). In dieser Baumstruktur wird das komplette Skript in sogenannte Ausdrücke zerlegt. Zur Auswertung dieser Ausdrücke wird es eine einzelne Funktion innerhalb des AutoIt-Interpreters geben. Wenn man diese Funktion ausfindig machen kann und (meinetwegen auch live während der Ausführung) so modifiziert, dass diese unmittelbar vor dem Return eine von uns geschriebene Blockier-Funktion aufruft... Dann haben wir eigentlich schon eine schrittweise Ausführung hinbekommen.

Man korrigiere mich, wenn ich falsch liege oder was übersehen habe.

Ich möchte aber nochmal darauf hinweisen, dass das rein theoretische Überlegungen sind. Außer, irgendwer holt eine offizielle Erlaubnis des Rechteinhabers ein.

alpines Ja, das stimmt. Aber eine Suche nach Teilbegriffen habe ich nicht aus der Fragestellung rausgelesen, wenngleich das schon sinnvoll wäre.

Professor Bernd Grundsätzlich hast du recht. Allerdings funktioniert ein Dictionary intern anders als ein "normales" Array und hat daher Vorteile bei den Zugriffszeiten. Für mehr Infos siehe https://de.wikipedia.org/wiki/Hashtabelle.

Vom Gefühl her würde ich ein Dictionary oder eine HashTable ausprobieren. Die weisen ja auch quasi konstante Zugriffszeiten auf.

Edit:

$sInFilePath = "C:\Program Files (x86)\AutoIt3\SciTE\api\au3.api"


$oDict = ObjCreate("Scripting.Dictionary")


$sFileContent = FileRead($sInFilePath)
$aLines = StringSplit($sFileContent, @CRLF, 3)
For $sLine In $aLines
$aParts = StringSplit($sLine, " ", 3)
$oDict($aParts[0]) = $sLine
Next


$hTimer = TimerInit()
$s = $oDict("ConsoleWrite")
$nTime = TimerDiff($hTimer) / 1000
ConsoleWrite("Output: " & $s & @CRLF)
ConsoleWrite("Time: " & StringFormat("%.10f", $nTime) & @CRLF)

So irgendwie. Theoretisch könnte man auch von Hand einen BST implementieren.

Hi,

grundsätzlich kann man da natürlich was bauen, klar. Aber ich stelle mir die Frage, warum das nötig sein soll. Reicht nicht einfach HTTPS?

cURL sollte eigentlich dafür nicht nötig sein - im Gegenteil, das wird vermutlich eher noch Probleme schaffen.

cURL ist eine externe Anwendung (*.exe), die Du aus AutoIt heraus aufrufen würdest. Dabei musst Du sämtliche Parameter als Startparameter für die EXE übergeben. Dazu muss alles korrekt maskiert/escaped sein (Anführungszeichen, Sonderzeichen, Leerzeichen etc..). Das führt üblicherweise zu Problemen.

Eleganter und weniger fehleranfällig wäre es, hier direkt auf WinHTTP oder WinInet zurückzugreifen. Beide Bibliotheken sprechen - ebenso wie cURL - HTTP. Und nichts anderes ist CalDAV ja am Ende: Ein XML-String, der per HTTP übertragen wird.