What is the better way to program a read (or a write)

[pdgnr]

Good day all,

a fsuipc_read (or a write) seems to be performed very fast, but the fsuipc_process uses much more CPU.

So the question is: is it more efficient to make a lot of read and then only one fsuipc_process or is it better to issue a fsuipc_process after each fsuipc_read (or couple of read...) ?

Thanks by advance,

Robert

[Pete Dowson]

a fsuipc_read (or a write) seems to be performed very fast, but the fsuipc_process uses much more CPU.

That's because the read and write calls merely add the request to a queue in your memory. They never leave your program. Only the Process call does anything -- that takes a while because it has to get windows to switch to the FS process, pass the data built up to FSUIPC, wait for the reply, then switch back.

So the question is: is it more efficient to make a lot of read and then only one fsuipc_process or is it better to issue a fsuipc_process after each fsuipc_read (or couple of read...) ?

NEVER do a Process after each read. The whole point of splitting the specification of what you want to read and write from the actual doing of it was for efficiency. You'll not only slow your program down, but you'll slow FS as well.

Ideally ALL of the things you want to read and write in each cycle of your program should be built up and sent in one Process call. The cycle is best if it is timed to be either the same as one FS frame, or a multiple of it (if you don't need things so urgently). If you get, say, 20 fps consistently from FS (set the limiter to something suitable) then sending a Process every 50 mSecs (or every 100, 150 etc) is best.

The only exception to saving everything up for one Process is for those cases where what you write needs to be decided upon from what you read. Then you may need to read something, do some calcs, and write something. Even then it would be more efficient to spread that over two of the above cycles, so "Read --- Write & Read --- Write & Read --- etc.

Oh, there is one other exception but it isn't likely to arise. That's when the total data size adds to more than the max size for one Process call -- around 30000 bytes. Don't get anywhere near that.

Pete

[pdgnr]

Hi Peter,

thank you very much for this acurate answer. Synchronizing the process with the frame rate of FS is something I never thought before...

Best regards,

Robert