anchor.diff:  **** at-most-once if you can afford losing messages
   **** at-least-once (+ message numbering) otherwise
   *** use async I/O if you can
  +
  +** architecture
  +*** prefer many small servers to few big servers
   
   * Less frequent sources of performance issues
   
  
positive.code: *** replace Lists and Strings by arrays
  *** cryptography is slow
  *** XML parsing is slow
  *** serializin/deserializing is slow
  *** creating a regexp is slow
  *** prefer StringBuilder over String.format
  *** avoid polling
  
negative.code: * performance improvement process (see JPT)
  ** no premature optimization
  ** have a performance objective
  ** concentrate of the 20% of the app that is responsible for 80% of the load
  ** one issue often hides other issues
  ** first actions might not show any improvement. Yet, don't despair!
  ** test in real-life conditions (DB size, # simultaneous users, server sizing...)
  ** OS contention, then GC issues, then code optimization
  ** ...
  