Optimising data transfers

For most applications, if you write inefficient code, your program will still work despite the fact that it executes slowly. The speed might affect the usability of the program, but not its functionality. However, when writing to a communications API, inefficient code can cause an application to fail. Additionally, the usual considerations still apply  —

• resources on hand-held devices are more precious than on less portable machines

• for a genuinely multitasking operating system, there are system-wide benefits in making code as fast as possible

The following points don’t have the prescriptive status of rules, and breaking them will not generate any compiler or linking errors. However, if you have real-time code to write, they can make the difference between applications that work and ones that don’t.

The larger the buffers that are used, the fewer calls to the comms server there will be. This means that larger buffers result in a better utilisation of the available CPU bandwidth. Reading and writing single characters is generally deprecated as it makes fast communication virtually impossible and can adversely affect the responsiveness of the system. The only real exception to this rule is where a single character corresponds to a specific real-time event, such as a keypress requiring a single character to be transmitted.

Descriptors are classes, with their own constructors and destructors. Creating and destroying them takes time. You should therefore try to re-use globally available buffers whenever possible instead of creating and destroying them as needed. In order to help you do this, both the Read() and Write() functions are available in variants that take a length parameter. When present, this overrides the length of the descriptor which would otherwise be used as the number of characters to be read or written.

Descriptors are used as data buffers because they offer an extremely flexible and effective mechanism for passing data between functions. While it is possible to input and extract data to and from descriptors by treating them like ordinary C arrays, the fact that such code may look the same in both cases is deceptive. The C [] array indexing operators are actually overloaded in the definition of the descriptor classes, and indexing descriptors is far less efficient than using pointer arithmetic to get to the contents.

Time-outs should ideally be used for trapping error conditions. Where a fast response to specific incoming data is required you should try to configure the port appropriately. In particular, early termination of read requests describes how read requests can be configured to terminate early. You should take every opportunity offered to offload as much processing as possible on to the comms drivers by configuring ports properly and choosing the right variant of each data transfer call.

If your are transmitting blocks of data which have a significant processing overhead between each serial port write, make use of the feature for early termination of write requests to avoid unnecessary waits between successive writes of data.

Be very careful when using ReadOneOrMore() in a program loop as it may not necessarily be the most sensible function to choose. The problem is that any time saved through slower data throughput or an increase in efficiency in the rest of the code is liable to be eaten up, as the function just reads smaller and smaller amounts of data with each iteration until you reach the limiting case, when you are simply using ReadOneOrMore() to pick up individual characters. The code in the GlassTerm example does reads with tenth of a second time-outs, to preserve the echoplex nature of typing on a terminal. It only calls ReadOneOrMore() after a time-out has occurred to read characters from the input buffer. The trade-off, is that the call to the comms server has to be renewed 10 times every second even when no data is being transferred. Arguably, this is a more acceptable overhead than that incurred if data were coming in rapidly and ReadOneOrMore() was calling the comms server up to 2000 times every second.