This section provides some information on how a client application can be optimised to improve data transfer performance.
This section is not a tutorial because some performance improvements must be balanced with other goals for the application.
The larger the buffers that are used, the fewer requests required to the Serial Communications Server. Use larger buffers to reduce the application's CPU requirements.
To create or destroy a Descriptor requires CPU time to complete the constructor or destructor. Performance is increased by reducing the number of requests to create or destroy a Descriptor. To reduce the number of Descriptor create requests, create a global Descriptor for the data buffer. A global Descriptor is a Descriptor that is available to all functions in the application.
The RComm::Read() and RComm::Write() functions are available in variants that take a length parameter. Use the length parameter when a global descriptor is used. If the length parameter is not used, the RComm::Read() and RComm::Write() APIs use the length of the Descriptor to define the number of characters to read or write.
Descriptors have C [] array indexing operators. Do not use the C [] array indexing operators since pointer arithmetic is faster.
Configure the ports so that the Serial Communications Server manages all the processing:
Set time-outs to trap error conditions
Set termination characters for the protocol. See How to Terminate Read Requests Early: Tutorial
Configure the ports so that the Serial Communications Server manages all the processing:
Set ports to return early when no response from the remote device is expected, or where there is a lot of processing to prepare the next block of data to be sent. See How to Terminate Write Requests Early: Tutorial
If RComm::ReadOneOrMore() is used in a loop, the function may cause slower performance. This slower performance is the result of the loop reading smaller and smaller blocks until on single characters are read.
The Glass Teletype example uses a time-out of one tenth of a second. This time-out has two purposes:
The time-out simulates the delay effect of a terminal
The time-out allows the RComm::Read() API to be used while not causing a large load on the CPU
If the time-out expires, the Glass Teletype example then calls ReadOneOrMore().
The trade-off is that the RComm::Read() call to the Serial Communications Server has to be renewed 10 times every second even when no data is being transferred. This was considered a smaller overhead than that incurred if data were coming in rapidly and as a result ReadOneOrMore() was called up to 2000 times every second.