Performance - BufferedSerial::write byte by byte or in chuncks

[ladislas]

original post here: https://forums.mbed.com/t/performance-question-bufferedserial-write-byte-after-byte-or-in-chuncks/18671

Hi there!

I'm finding myself scratching my head about how to deal with large buffers sent to BufferedSerial::write() as I was working on optimizing/refactoring our logger.

should we write the buffer byte after byte or in chuncks?

The data is stored in a CircularBuffer (fifo) and the call to BufferedSerial::write() is made with an event queue in a low priority thread to avoid blocking important stuff and only output logs when nothing else is happening.

Current implementation writing byte after byte looks like this:

inline void process_fifo()
{
	while (!buffer::fifo.empty()) {
		auto c = char {};
		buffer::fifo.pop(c);
		_default_serial.write(&c, 1);
	}
}

Chunk implementation looks like that:

inline auto process_buffer = std::array<char, 64> {};

// ...

inline void process_fifo()
{
	while (!buffer::fifo.empty()) {
		auto length = buffer::fifo.pop(buffer::process_buffer.data(), std::size(buffer::process_buffer));
		_default_serial.write(buffer::process_buffer.data(), length);
	}
}

We first pop the data in a 64-byte std::array then pass this buffer to BufferedSerial::write().

The assumptions are that using the temporary 64-byte std::array buffer can:

• reduce the number of calls to BufferedSerial::write()
• empty the CircularBuffer (fifo) faster allowing it to be filled faster as well
• allow the compiler to copy/move bigger chunks of memory and optimize things

But to be honest I'm not sure 😂

Using chuncks adds 64 bytes of RAM and 64 bytes of flash, which is something we can live with.

But are my assumptions correct? Am I optimizing anything? Or doing premature pessimization?

Our test code seems to be running the same, character output is the same:

• input 1988 characters/ms in fifo
• output 12 characters/ms to serial

So what do you guys think? Should we make the change? :)

For reference:

• current implementation - https://github.com/leka/LekaOS/blob/develop/libs/LogKit/include/LogKit.h
• PR - ⚡ (LogKit): Process fifo by chuncks of 64 bytes leka/LekaOS#1116

[JojoS62]

I would also guess that using 64 byte chunks are more efficient.
Mbed has a lot of error logging macros and also tracing built in, aren't these enough?

[ladislas]

I would also guess that using 64 byte chunks are more efficient.

Then let's do it ;) we can alway revert if need be.

Mbed has a lot of error logging macros and also tracing built in, aren't these enough?

Honestly, from my (very) short experience with those, they felt overly complicated and added even more strong deps w/ mbed on our code base.

We try to wrap mbed API in our own API like mbed/drivers/I2C to leka/drivers/CoreI2C. Our code depends on CoreI2C which itself uses mbed in it's implementation. This allows us to easily switch if needed.

It's also super helpful for unit testing as we can mock our own APIs very easily.

As for the logger, besides gaining experience writing one, we wanted something that does not interfere (or as little as possible) with the code flow. And we actually implemented it.

Our logger fixes two of mbed-traces compromises

The solution is not Interrupt safe. (PRs are more than welcome.)

We are interrupt safe as we dispatch the actual printing in a event queue with a low priority thread.

The solution is not thread safe by default. Thread safety for the actual trace calls can be enabled by providing wait and release callback functions that use mutexes defined by the application.

We are thread safe thanks to:

• mutexes
• different formatting and output buffers
• the use of a circular buffer for the final content to be sent for printing

We can also redirect the logs to whatever we want: LCD screen, files, BLE, etc. even multiple at the same time.

[multiplemonomials]

Hey Ladislas! It's been a minute. This is only tangentially related, but if you're using I2C on STM32 processors, you should really consider switching to Mbed CE. Not only did I rewrite all the docs, but I just finished rewriting the STM32 I2C HAL itself. I found a lot of issues, especially with the single-byte API, which has been bugged and unusable for four years. All the details here: #78

[ladislas]

@multiplemonomials moving to mbed-ce is on the top of my todo ;) I'll report the migration as soon as I start working on it.