title: Does FileStream.Seek() with SeekOrigin.Begin optimize for when no seeking is necessary?
body: <p>I have a class that reads image data a row at a time from large files using <code>FileStream</code>.  Internally, the files are broken into chunks, each of which looks like this:</p>
  
  <pre>
  =================
  | Header        |
  =================
  | Data I Want   |
  =================
  | Data I Ignore |
  =================
  </pre>
  
  <p>To read a row of data, I calculate which chunk has the row I want, <code>Seek()</code> to the appropriate offset, and read a fixed number of bytes.  When reading multiple rows from within a single chunk, I could actually skip all <code>Seek()</code> calls but the first, because the pointer is already where I want it after a <code>Read()</code>.  But I need to <code>Seek()</code> when jumping to a new chunk.  For simplicity, I always calculate the next row's absolute offset in the file and <code>Seek()</code> to it using <code>SeekOrigin.Begin</code>.  Is <code>FileStream.Seek()</code> (or the underlying <code>SetFilePointer()</code> native function) optimized to recognize that a given seek is a no-op?  If not, I should probably optimize my own code, as it's not exactly lightning-fast.</p>