CharSequenceEncoder uses CharBuffer.wrap and charset.encode to encode String data to its binary representation. There can be two optimizations made here:
CharSequenceEncoder uses typically UTF-8 encoding and Java's UTF-8 encoder requires significant computing time. It would make sense to detect this case and whether netty is on the class path to use netty's optimized UTF-8 encoding via ByteBufUtil.writeUtf8(…)
Encoding creates a new unpooled ByteBuffer when calling Charset.encode. Netty's ByteBufUtil.encodeString() can encode a String to a pooled buffer that reduces GC pressure.
It would make sense to detect this case and whether netty is on the class path.
It would not make sense, unfortunately: whether netty is on the class path is not a valid trigger. Users can choose to use a different DataBuffer implementation, or—when using the webclient on Tomcat, Jetty, or Undertow—ByteBuf will be on the classpath, but should only be used for the client-side; not server-side.
We could check whether a data buffer is an instance of NettyDataBuffer, and then call getNativeBuffer() to get access to the ByteBuf.
However, I think that's a bit ugly, so I'd rather expose the necessary functionality through the DataBuffer and DataBufferFactory abstractions, delegate to Netty's ByteBufUtil for NettyDataBuffer, and use a different, less optimal implementation for the DefaultDataBuffer.