TTask.Run( hat im Debugger lange Startverzögerung

[Rollo62]

Hallo zusammen,

ich suche gerade woran die lange Verzögerung bei TTast.Run( liegen kann,
und habe da ein paar interessante Entdeckungen gemacht.

! Mir geht es hier nicht um TThread-Alternativen, sondern nur darum ob es eine Verzögerung beim erstan TTask-Aufruf gibt, und wenn ja warum.

Die generelle Nutzung von TTask.Run mache ich so wie hier

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
begin

        Memo_Log( 'PREPARE via Run' );   // <-- hier ist der Timestamp auf 0

        TTask.Run(
            procedure
            begin
                Memo_Log_Async( '    BEGIN via Run' );  // <-- hier ist der Timestamp auf bis zu 6000 ms ??

                FTaskRunning := 1; // Run

                while FTaskRunning <> 0 do
                begin
                    Sleep(25);
                    ...
                end;

                Memo_Log_Async( '    END via Run' );

            end);

end;

Ich habe eine kleine TestApp angehängt (mit etwas zusätzlichem Test-Code drumrum),
in der App habe ich noch versucht die Alternative mit Create-Start zu Testen, mit ähnlichem Ergebnis:
Nach dem ersten App-Start im Debugger braucht der Aufruf von TTask.Xxx bis zu 6 Sekunden !
Das könnte eventuell am Aufbau eines ThreadPools liegen, aber auch dafür wäre die Zeit enorm.

Zum Testen der Verzögerung muss die App neu gestartet werden, nur der 1. Start und 1.Aufruf entweder Run oder Create.Start ist verzögert.

Delphi-Quellcode:

procedure TForm1.Button2Click(Sender: TObject);
var
    LTask: ITask;

begin

        Memo_Log( 'PREPARE via Create-Start' );  //<-- Hier ist der Timestamp auf 0

        LTask := TTask.Create(       //<-- Hier gibt es ein Blocking für geraume Zeit
            procedure
            var
                LCnt : Integer;
            begin
                Memo_Log_Async( '    BEGIN via Create-Start' );   // Hier ist der Timestamp auch bis zu 6000 ms

                FTaskRunning := 1; // Run

                LCnt := 0;

                while FTaskRunning <> 0 do
                begin

                    Sleep(25);
                    ...

                end;

                Memo_Log_Async( '    END via Create-Start' );

            end);

        Memo_Log_Async( 'CALL START via Create-Start' );
        LTask.Start;


end;

Was ich herausgefunden habe ist:

• TTask.Run() verzögert bis zu 6sec. beim ersten App-Start
• TTask.Run() funktioniert beim zweiten+ TTask Aufruf dann wie erwartet (ein paar ms delay)
• TTask.Create.Start zeigt das gleiche Verhalten beim ersten App-Start
• TTask.Create.Start zeigt zusätzlich ein Blockieren des UI-Threads
  
• TTask.Create.Start läugt nach dem zweiten Start problemlos
• Es geht hier nur um die Verzögerung DIREKT NACH DEM APP-Start
• Der Fehler scheint nur im Debugger aufzutreten, hoffentlich nicht im Release
• Der Fehler scheint nicht unter Android aufzutreten
  

Ist das Verhalten unter iOS-Debugger bekannt, kann das jemand nachvollziehen ?
Ich teste im Moment auf einem aktuellen iPHoneX, aber ich denke das Problem ist auch auf anderen Geräten gleich.

Im Anhang ein Testprogramm, und Screenshots
TTask.Run() - lange Verzögerung zw. PREPARE und BEGIN
Anhang 51405

TTask.Create.Start - Blockieren MainThread
Anhang 51406

TTask.Create.Start - lange Verzögerung zw. PREPARE und BEGIN
Anhang 51407

Für eine kleine Hilfestellung oder Kommentierung wäre ich sehr dankbar,
auch wenn es am Ende z.B. gegen TTask und auf TOmniThread hinauslaufen sollte.

Ich habe jetzt leider keine Zeit mehr weitere Tests zu machen, ich möchte den Fall aber gerne mit einem guten Gefühl abschliessen.
Hat noch jemand solche seltsamen Erfahrungen mit dem TTask gemacht ?

[Schokohase]

Also ich habe eine VCL-Anwendung und da passiert bei

Delphi-Quellcode:

type
  TForm1 = class(TForm)
    Button1: TButton;
    Memo1: TMemo;
    procedure Button1Click(Sender: TObject);
  private
    { Private-Deklarationen }
    procedure LogMsg(const AMsg: string);
  public
    { Public-Deklarationen }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);
begin
  LogMsg('Button1Click ENTER');
  TTask.Run(
    procedure
    begin
      LogMsg('Task ENTER');
      TThread.Sleep(2000);
      LogMsg('Task EXIT');
    end);
  LogMsg('Button1Click EXIT');
end;

procedure TForm1.LogMsg(const AMsg: string);
var
  callingNow: TDateTime;
begin
  callingNow := System.SysUtils.Now();
  TThread.Synchronize(nil,
    procedure
    var
      loggingNow: TDateTime;
    begin
      loggingNow := System.SysUtils.Now();
      Memo1.Lines.Add(string.Format('%s - %s - %s', [FormatDateTime('hh:nn:ss.zzz', loggingNow), FormatDateTime('hh:nn:ss.zzz', callingNow), AMsg]));
    end);
end;

das

Code:

20:08:53.385 - 20:08:53.385 - Button1Click ENTER
20:08:53.385 - 20:08:53.385 - Button1Click EXIT
20:08:53.386 - 20:08:53.385 - Task ENTER
20:08:55.387 - 20:08:55.387 - Task EXIT

Also eigentlich kein Delay (was der Rede wert wäre).

Ok, das war ohne Debugger, mit Debugger sieht es so aus

Code:

20:12:50.266 - 20:12:50.266 - Button1Click ENTER
20:12:50.266 - 20:12:50.266 - Button1Click EXIT
20:12:50.317 - 20:12:50.315 - Task ENTER
20:12:52.319 - 20:12:52.319 - Task EXIT

Unter iOS kann man durchaus ein langsameres Verhalten erwarten gerade weil da auch die Kommunikation zwischen Device und Debugger wesentlich umständlicher ist.

Prüfst du das mit einem echten Device oder mit dem Simulator?
(Ich würde beim Simulator eine bessere Performance erwarten)

[Rollo62]

Hallo Schokohase,

dankesehr fürs checken.
Ja ich Teste mit FMX und iOS, aus einem iPhone X, andere iOS Geräte hatte ich bis jetzt nicht gecheckt.

Etwas mehr Delay wäre ja kein Problem für mich, aber 6 Sekunden bis zum Start des Tasks ???
Und das nur wenn die App das erste mal startet im Debugger, danach kommen weitere Aufrufe auch sofort (<= 10 ms).

Wohlgemerkt das scheint nur unter folgenden Bedingungen zu passieren:
- echtes iOS Device (momentan iPhone X mit iOS 12.3), kein Simulator
- Android habe ich nur kurz gecheckt, da gibt es aber kein solch extremes Delay
- Das Delay kommt anscheinend NUR beim ersten Aufruf des TTask.Run
- und wohl NUR beim Debuggen mit der IDE
- selbst wenn die selbe App dann mit Debug-Daten lokal auf dem iPhone nochmal gestartet wird ist das Delay weg.

Es sieht so aus als würde beim ersten Start von TTask irgendwas initialisiert, eventuell auch über den Debugger, wie TThreadPool o.ä.
Wäre alles OK, nur eben nicht mit 6 Sekunden, und teilweise mit Blockieren des UI-Threads.

Ich habe in der TestApp schon nach allen möglichen Gründen, Deadlocks, Synchronisierungen, etc. gesucht, und einiges probiert, deshalb die zusätzlichen Abfragen dadrin.
Aber das scheint es nicht zu sein.

[hoika]

Hallo,
hilft das hier?

https://stackoverflow.com/questions/...the-first-time


Stichwort: eigener Thread-Pool

[Rollo62]

Hallo hoika,

dankesehr, ich hatte schon nach bekannten Fällen im Web gesucht, das hier aber nicht gefunden.
Ich werde wohl mal versuchen irgendwas mit eigenem ThreadPool anzustellen,
da komme ich aber womöglich erst morgen wieder dazu damit weiterzuspielen.

Anstatt direkt ein eigenes TThreadPool Objekt anzulegen, gäbe es da nicht auch Möglichkeiten an dem Default-Objekt etwas zu "optimieren" ?
Aber ausser "Priority" und "ProzessorCount" scheint da nicht viel relevantes möglich zu sein.
Mit ThreadPools habe ich bisher nicht viel gemacht, sondern das immer nur im Default verwendet.

[hoika]

Halo,
mit Thread-Pools habe ich noch gar nichts gemacht.
Ich habe deine Frage in Englische übersetzt und gegoogelt ... ;)