Data Transfer Performance Guidelines

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.

Buffer size

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.

Global Buffers

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.

Indexing descriptors

Descriptors have C [] array indexing operators. Do not use the C [] array indexing operators since pointer arithmetic is faster.

Read Requests

Configure the ports so that the Serial Communications Server manages all the processing:

Write Requests

Configure the ports so that the Serial Communications Server manages all the processing:

ReadOneOrMore()

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.

Related concepts
Code efficiency
Related reference
Handshaking