qtforum.de

Hallo,

ich habe ein kleines Research Projekt angefangen, um eventuell die Performance bei der Handhabung von QObjects , unter bestimmten Umständen, zu verbessern. Generell geht es darum, erstellte Qt Worker Objects automatisch in mehrere Threads zu verlagern. Nun aber nicht einfach pro Worker-Object einen Thread verwenden, sondern ein Thread (bzw. dessen QEventLoop) soll sich gleichzeitig um die Ausführung der Signals und Slots von mehreren QObjects kümmern.

Genaueres habe ich in einem Blog Post geschrieben:
http://thehumbleguy.de/qt-parallel-event-loop/

Der Source dazu liegt in einem Git Repository auf GitHub:
https://github.com/mfreiholz/qt-parallel-event-loop

Nun würde mich interessieren was ihr davon haltet und evtl. eine Diskussion darüber anstoßen, in wie weit so etwas sinnvoll ist.

Grüße
THG

Macht man das nicht eh, wenn man threadpools verwendet.
den pool wiederum kann man in nen eigenes QThread object mit Eventqueue(exec) packen, dann haendelt der auch die signale slots zwischen pool und worker.

Wenn eh schon worker bauen musst, dann kannst auch gleich nen threadpool nehmen.
wenn man den Pool auf 1 stellt, hat man auch alles quasi seriell ...

Ich find das ist nicht so viel Aufwand ...
und die anforderungen koennen an der Stelle recht speziell sein.
weiss nicht, ob sich dafuer ne bib lohnt ....

und wenn du auf "power" aus bist, isses doch eh generell besser nur gui thread + (anzahl der physikalischen Prozessoren) threads aufs mal laufen zu lassen (ressourcen).
mehrere threads nebeneinander bringen doch keinen vorteil, solange sie nicht blockieren.
Also sollte eher das ziel sein, nichtblockierende, oder so wenig wie möglich blockierende worker zu bauen.
die harmonieren dann perfekt mit nem threadpool ....
Also lieber nen kemplexeres abhanegigkeitsmanagment .

Ciao ....