keiner mehr ne idee :S

Probiers halt mal aus, ob's an dem Synchronize liegt: Zeilen auskommentieren und dann messen.
Ansonsten: Probiers erst mal ohne Thread-Priority Spielereien und spendier dem Code am Beginn und am Ende der Execute Methode mal etwas Code zur Zeitmessung (GetTickCount)
Generell: nicht vermuten wo es langsam ist, sondern messen!

Grüße,
Uli

Naja, was du machst ist ja explizit nicht mehrere Threads parallel laufen zu lassen, sondern nach dem Ende eines Threads den nächsten Datensatz anzufordern.

Du rechnest also weiter hintereinander, nicht parallel, nur dass die Threadsynchronisierung dazukommt. Das kann nur länger dauern.

Zudem blitzen die Threads nur kurz auf, die sind bei mir in dem Beispielprogramm nach vielleicht einer Sekunde jeweils fertig. Das macht auch nicht ganz so viel Sinn.

Besser wäre, wenn du gleich mehrere Aufträge verteilst, damit der Thread auch ein bisschen was zu tun hat und außerdem auch mehrere Threads parallel laufen lässt. Stichwort Threadpool zum Beispiel.
Außerdem solltest du die Zuweisung an einen bestimmten Kern weglassen. Windows verteilt das in der Regel schon am besten alleine.

@ULIK:
Wozu ins Blaue daneben raten, wenn du im Quelltext doch schnell sehen kannst, dass erst in ThreadDone der nächste Datensatz angefordert wird usw.?

Zitat von jaenicke:

@ULIK:
Wozu ins Blaue daneben raten, wenn du im Quelltext doch schnell sehen kannst, dass erst in ThreadDone der nächste Datensatz angefordert wird usw.?

Indem ich mir den Quellcode nur schnell am Morgen angeschaut hab?
Mir ging's eigentlich hauptsächlich darum, daß man bei Performanceproblemen halt erst mal messen sollte und wenn der TE schon die Synchronisation erwähnt, dann halt mal ausprobieren und schauen, ob es das ist.

Grüße,
Uli

SetThreadAffinityMaskByID(getcurrentthreadid,1);
Dir ist schon klar, daß das Create im Kontext des Hauptthreads aufgerufen wird? Der obige Befehl wirkt sich somit lediglich auf den Hauptthread aus und nicht auf den des gerade erzeugten TThread-Objekts.

Du kannst aber auch mal testen, wie das Verhalten ist, wenn du die beiden Synchronize-Aufrufe auskommentierst. Damit könnte man eventuell die Thread-Synchronisation als Bremse ausschließen.

Nebenbei wichtig: welche Delphi-Version nimmst du?

Zitat von Uwe Raabe:

SetThreadAffinityMaskByID(getcurrentthreadid,1);
Dir ist schon klar, daß das Create im Kontext des Hauptthreads aufgerufen wird? Der obige Befehl wirkt sich somit lediglich auf den Hauptthread aus und nicht auf den des gerade erzeugten TThread-Objekts.

Du kannst aber auch mal testen, wie das Verhalten ist, wenn du die beiden Synchronize-Aufrufe auskommentierst. Damit könnte man eventuell die Thread-Synchronisation als Bremse ausschließen.

Nebenbei wichtig: welche Delphi-Version nimmst du?

>achso ich dachte man musst das im create nutzen... naja ich habs mal weggemacht
>auch das ausklammern der synchros hat keinen effekt auf die geschwindigkeit
>ich gurke auf einer version 6 rum...

Zitat von jaenicke:

Naja, was du machst ist ja explizit nicht mehrere Threads parallel laufen zu lassen, sondern nach dem Ende eines Threads den nächsten Datensatz anzufordern.

Du rechnest also weiter hintereinander, nicht parallel, nur dass die Threadsynchronisierung dazukommt. Das kann nur länger dauern.

Zudem blitzen die Threads nur kurz auf, die sind bei mir in dem Beispielprogramm nach vielleicht einer Sekunde jeweils fertig. Das macht auch nicht ganz so viel Sinn.

Besser wäre, wenn du gleich mehrere Aufträge verteilst, damit der Thread auch ein bisschen was zu tun hat und außerdem auch mehrere Threads parallel laufen lässt. Stichwort Threadpool zum Beispiel.
Außerdem solltest du die Zuweisung an einen bestimmten Kern weglassen. Windows verteilt das in der Regel schon am besten alleine.

> naja ich wär erstmal froh, wenn das mit einem Thread vernünftig läuft, daher lasse ich bisher nur einen laufen
> ich möchte ja, das erst nachdem ein Paket bearbeitet wurde, der Server kontaktiert wird, und ein neues Paket angefordert wird, demnach muss ich warten bis der thread fertig ist. Außerdem, macht eine threadsynchronisierung einen unterschied von fast 14 sek aus?
>Zu deinem PC: was für eine CPU hast du 0o. Im normalen Programm schaff ich ein Paket in ca. 7sek, mit einem Thread ca. 20 sek. (Dual - Core E6300 mit 1,86GHz, bei nem Kumpel 2,8GHz ca. 4 und 12 sek.). Von daher wenn ich die Pakete größer mache, dann muss ich ja 81.450.625 Schleifendurchgänge Rechnen, anstatt ca. 800.000 ... das dauert dann viel zu lange...

Mal so rein grundsätzlich:
Bei reinen Rechenthreads darf man maximal so viele Thread benützen, wie unabhängige CPU-Kerne im System vorhanden sind.
Beispiel:
4 logische Cores (Hypherthreading), 2 physische Cores
Hier darf man maximal 2 Rechenthreads verwenden.
Würde man 4 Threads verwenden, dann würde zwar jeder logische Core voll ausgelastet werden, die Gesamtperformance wäre aber schlechter als bei nur 2 Threads.

klingt logisch^^... ich hab ja 2 "echte" kerne... aber es fluppt halt nichtmal bei einem Thread :/