2

I'm looking for IPC with high performance in Qt (v5.3) on Windows. In my final situation, I will have 3 (or more) producer process and one consumer process.

Before that, I made some tests using 1 producer thread and 1 consumer thread, using both QLocalSocket/QLocalServer (example) and QSharedMemory (example), and I have been surprised that the times are comparable.

In particular I got the following results (from first message till last message received):

Sending/Writing 1000 string message: QSharedMemory: 1020ms, QLocalSocket 1010ms Sending/Writing 5000 string message: QSharedMemory: 5010ms, QLocalSocket 5090ms Sending/Writing 10000 string message: QSharedMemory: 10097ms, QLocalSocket 10850ms

The questions are:

  • Do you agree with this results or I probably wrong something in my code ?
  • Are there some IPC methods with better performance in Qt ?

Thanks in advance. arthur86

UPDATE 23/10/2014

I take more time to investigate about this doubt, and I found a reasonable response. I discover that a big percentage of the previous time is used by context switch between thread. In particular, if I remove Thread::msleep(0); at the end of each cycle I'm able to reach lower computational time.

Eg.

  • 1000 string message: less than 100ms both for QLocalSocket and QSharedMemory
  • 5000 string message: less than 300ms both for QLocalSocket and QSharedMemory
  • 10000 string message: less than 1000ms both for QLocalSocket and QSharedMemory

I think removing Thread::msleep(0) is no a good idea. Isn't it ? Could you suggest me some methods to improve performance with sleep instruction ?

arthur86
  • 531
  • 1
  • 3
  • 20
  • 1
    Why would you wish to sleep your thread when pretty much every modern processor is dual core at last? We will not be able to do much without some code. – Vinícius Gobbo A. de Oliveira Oct 23 '14 at 15:01
  • @ViníciusGobboA.deOliveira I'm sorry, but the application will be deployed in embedded system with single core CPU. The code I used is the same of the linked examples. – arthur86 Nov 01 '14 at 18:02
  • Interesting! Using an event driven approach wouldn't be better? So the task will still sleep, and wake only when there is work to do? This way I believe you will get as few context switches as possible. – Vinícius Gobbo A. de Oliveira Nov 01 '14 at 18:09
  • I think this is possible in case of threads worker, I don't know if it's possible to do that between processes. – arthur86 Nov 01 '14 at 18:13
  • I don't have an example for this [my Google skills seems not enough...], but I believe with `QSharedMemory` and `QSystemSemaphore` is possible. Take a look at the `QSharedMemory.lock()` method, it will lock the shared memory region (oh! really??), while `QSystemSemaphore` may provide a counter for how many "messages" are pending. – Vinícius Gobbo A. de Oliveira Nov 01 '14 at 19:10
  • is there some general guideline / pro/con when to use QLocalSocket and when QSharedMemory? – jaronimoe Jan 07 '16 at 15:45

0 Answers0