#### Optimizations

A naive implementation would simply regenerate all resources, of all subscribed types, for each client, on any configuration change. However, this scales poorly. As a result, we have many levels of optimizations to avoid doing this work.

    Appendable secretlyAWriter = new StringWriter();
    result = CharStreams.asWriter(secretlyAWriter);
    assertSame(secretlyAWriter, result);
  }

  // CharStreams.copy has type specific optimizations for Readers,StringBuilders and Writers

  public void testCopy() throws IOException {
    StringBuilder builder = new StringBuilder();
    long copied =
        CharStreams.copy(

    Appendable secretlyAWriter = new StringWriter();
    result = CharStreams.asWriter(secretlyAWriter);
    assertSame(secretlyAWriter, result);
  }

  // CharStreams.copy has type specific optimizations for Readers,StringBuilders and Writers

  public void testCopy() throws IOException {
    StringBuilder builder = new StringBuilder();
    long copied =
        CharStreams.copy(

		Name:   "compat",
		Usage:  "enable strict S3 compatibility by turning off certain performance optimizations",
		Hidden: true,
	},
	// This flag is hidden and to be used only during certain performance testing.
	cli.BoolFlag{
		Name:   "no-compat",
		Usage:  "disable strict S3 compatibility by turning on certain performance optimizations",
		Hidden: true,
	},
}

// Help template for minio.
var minioHelpTemplate = `NAME:

import java.io.StringWriter;
import java.nio.Buffer;
import java.nio.CharBuffer;
import java.util.Random;

/**
 * Benchmarks for {@link CharStreams#copy}.
 *
 * <p>{@link CharStreams#copy} has type specific optimizations for various common Appendable and
 * Reader implementations, this compares the performance of the different options.
 */
// These benchmarks allocate a lot of data so use a large heap
@VmOptions({"-Xms12g", "-Xmx12g", "-d64"})

import java.io.StringWriter;
import java.nio.Buffer;
import java.nio.CharBuffer;
import java.util.Random;

/**
 * Benchmarks for {@link CharStreams#copy}.
 *
 * <p>{@link CharStreams#copy} has type specific optimizations for various common Appendable and
 * Reader implementations, this compares the performance of the different options.
 */
// These benchmarks allocate a lot of data so use a large heap
@VmOptions({"-Xms12g", "-Xmx12g", "-d64"})

    checkElementIndex(index, size);
    // requireNonNull is safe because we guarantee that the first `size` elements are non-null.
    return (E) requireNonNull(array[index]);
  }

  // TODO(lowasser): benchmark optimizations for equals() and see if they're worthwhile

  // redeclare to help optimizers with b/310253115
  @SuppressWarnings("RedundantOverride")
  @Override
  @J2ktIncompatible // serialization

In all these examples, the solution is the same:
use explicit synchronization.
</p>

<h2 id="badcompiler">Incorrect compilation</h2>

<p>
The Go memory model restricts compiler optimizations as much as it does Go programs.
Some compiler optimizations that would be valid in single-threaded programs are not valid in all Go programs.
In particular, a compiler must not introduce writes that do not exist in the original program,

   * even to an intermediate buffer) should be considerably more efficient than potentially
   * copying the CharSequence to a String and then calling getBytes(Charset) on that String, in
   * reality there are optimizations that make the getBytes(Charset) approach considerably faster,
   * at least for commonly used charsets like UTF-8.
   */

  @Override
  @CanIgnoreReturnValue
  public final Hasher putByte(byte b) {

	for i := range listener.listeners {
		addrs = append(addrs, listener.listeners[i].Addr())
	}

	return addrs
}

// TCPOptions specify customizable TCP optimizations on raw socket
type TCPOptions struct {
	UserTimeout int // this value is expected to be in milliseconds

	// When the net.Conn is a remote drive this value is honored, we close the connection to remote peer proactively.