Reverted AsyncResponseStream buffer to cbuf which is considerably faster than StreamString

[mathieucarbou]

This PR fixes an issue discovered in OpenDTU (see: tbnobody/OpenDTU#2535).

The replacement of cbuf by StringStream is definitely slower (3-4 times). Even calling setTimeout(0) to inhibit the timed read with readBytes() does not help speeding up.

This PR reverts the code and also provides a MRE helping isolate the problem / reproduce it.

The use of StringStream was causing several issues like:

• throttling within slow response (poll events)
• TWDT could trigger because of the slow StringStream

Note: this issue is only visible for big payloads: this OpenDTU endpoints uses a buffer of 40k.

[me-no-dev]

Any idea why StreamString is so slow?

[mathieucarbou]

autocannon -c 1 -d 30 http://192.168.4.1/

with cbuf

with StreamString

• CRASH if we not disable TWDT with -D CONFIG_ASYNC_TCP_USE_WDT=0
• lot of logs: [ 29448][D][AsyncTCP.cpp:173] _get_async_event(): coalescing polls, network congestion or async callbacks might be too slow!

setting a timeout with setTImeout(0) to avoid a 1 sec wait time does not help.

Analysis:

The perf of StreamString is really bad because of several things:

1. virtual size_t readBytes(char *buffer, size_t length); is not overridden, and the default implementation is doing a timed read and calls several times read()
   2.read() calls each time String::remove(0, 1), which is doing a memmove() of the nearly complete buffer for each read.

So if we have a bufferSize of 40k like in the OpenDTU project, reading causes 40960 calls to read(), each call doing a memmove of the remaining buffer.

That's super slow.

So this PR reverts to cbuff until StreamString perf is fixed in Arduino Core.

About StreamString inefficiency with large buffers:

The problem is the inefficiency between StreamString and String operations.

• First, StreamString should override readBytes() method to avoid calling read() repeatedly.
• Optionally the class should be modified for better perf with an flag preventing String mutations when read starts and also keep an index of the current position. This will prevent concurrent read / write and will avoid all the memory moves.

There is a tradeoff to make:

1. having the String in memory reduced after each read to really match the remaining bytes (slower - uses more heap because of copies)
2. or keep the String in memory as-is, immutable, and add indexes in StreamString to iterate over the String (faster and no move or copy - uses less heap but a steady mount of heap matching the initial String size)