<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix"><font face="Helvetica, Arial,
        sans-serif">On 12/30/2013 04:23 PM, Tom Metro wrote:<br>
      </font></div>
    <blockquote cite="mid:52C1F27E.40104@gmail.com" type="cite"><font
        face="Helvetica, Arial, sans-serif">I thought there was going to
        be a server reboot/reset/rebuild between runs.
        <br>
      </font></blockquote>
    <font face="Helvetica, Arial, sans-serif">It will.<br>
      <br>
    </font>
    <blockquote cite="mid:52C1F27E.40104@gmail.com" type="cite">
      <font face="Helvetica, Arial, sans-serif">The closest thing to
        real-world is having a fully empty cache, but I can't see any
        way that can be accomplished during development on a shared
        server.
        <br>
      </font></blockquote>
    <font face="Helvetica, Arial, sans-serif">...and such should be the
      case, or as close to it as possible.<br>
      <br>
    </font>
    <blockquote cite="mid:52C1F27E.40104@gmail.com" type="cite"><font
        face="Helvetica, Arial, sans-serif">
        Ideally while testing you should be benchmarking small portions
        of your code, so the cache will fill on the first run, and you
        have a good chance they'll remain populated for several
        subsequent runs, despite other users on the system hitting other
        files.
      </font><font face="Helvetica, Arial, sans-serif"><br>
      </font></blockquote>
    <font face="Helvetica, Arial, sans-serif">No need to worry too much
      about this.  The server won't be 'shared' at the time it's running
      the formal competition code benchmarks.  It will have been
      completely reverted to its state before the contest began.  Code
      will be cloned from github when it's time to run.  Before each
      run, the server will be rolled back.<br>
      <br>
      It's wholly contained in a virtual machine for this reason.  The
      encasing hardware/host will be totally idle other than its task of
      running the VM.  We needed the ability to "reset" the contest
      server to a pristine state for each contestant, and having a
      virtual machine made perfect sense.<br>
      <br>
      As advised from the beginning: code that depends on caching will
      be self-limited for the above reasons.<br>
      <br>
      --Tommy Butler<br>
    </font>
  </body>
</html>