Da hast du etwas in den falschen Hals bekommen :neutral:
Ich wollte damit weder C++ geringschätzen noch die Programmierkünste der gelernten Programmierer.
Wollte nur meine Erfahrung mit Skripten solcher professioneler C - Programmierer, die mir untergekommen sind pointiert zum Ausdruck bringen. Die durch Unkenntniss der Eigenheiten von Trainz-Skript zur besagten Performance-Keule geworden sind oder zumindest nicht optimal waren. (Polling ist wegen der dazu nötigen Verwendung des sleep(x) -Statements so giftig. Sicher eine unzulänglichkeit von Trainz-Skript, deshalb seitens von Auran davor gewarnt wird). Der "C-Profi" ist sich solcher Fallen nicht bewußt und wundert sich, warum die Performance so leidet.
ZitatEine alte Binsenweisheit in der Softwareentwicklung lautet, wer klar gegliederten und gut lesbaren Code produziert.....
In dieser Beziehung waren die angesprochenen Skripte durchaus vorbildlich.
Es macht ein Unterschied, ob ich eine Poll-Schleife in einer Regel verwende, die nur in einer Instanz läuft und von mir aus Messages in gewissen Zeitabständen sendet, oder ob ich solche Schleife in ein objektgebundenes Scriptlett einbaue, das in evtl. -zig Instanzen läuft. Der bekannte kommerzielle Add-On Hersteller erklärte einmal: gescriptete DKW`s werden wir künftig nicht einsetzen, denn wenn wir 40 davon auf unserer Strecke platzierten, ging performancemäßig nichts mehr. Eigentlich ein eindeutiger Hinweis, auf die beschriebene Problematik. (Und dabei müssten gerade bei DKWs keine Abfrageschleifen benutzt werden. Denn bei jeder Statusänderung einer Weiche sendet diese die Message "Junction" "toggle". Aber alle mir bekannten DKW-Skripte nutzen die alle 2 sec laufende Abfrageschleife.)
Wie gesagt, der Hund begraben liegt bei der Anweisung "sleep(x)" welche, wie mir berichtet wurde, kurzzeitig 100% CPU-Auslastung bewirkt. Ich habe auch sehr originelle Workarounds beobachtet, die sehr gut funktionieren und sleep in einem poll-thread vermeiden.
Btw. sehen wir uns beim TSSF-Treffen?