title: Is there a benefit in using old style `object` instead of `class` in Delphi?
body: <p>In Delphi <strong>sane</strong> people use a <code>class</code> to define objects.<br>
  In Turbo Pascal for Windows we used <code>object</code> and today you can still use <code>object</code> to create an object.  </p>
  
  <p>The difference is that a <code>object</code> lives on the stack and a <code>class</code> lives on the heap.<br>
  And of course the <code>object</code> is depreciated.  </p>
  
  <p><kbd>Putting all that aside:</kbd></p>
  
  <p><strong>is there a benefit to be had, speed wise by using <code>object</code> instead of class?</strong></p>
  
  <p><em>I know that <code>object</code> is broken in Delphi 2009, but I've got a special use case<sup>1)</sup> where speed matters and I'm trying to find if using <code>object</code> will make my thing faster without making it buggy</em><br>
  This code base is in Delphi 7, but I may port it to Delphi 2007, haven't decided yet.</p>
  
  <hr>
  
  <p><sup>1)</sup> Conway's game of life</p>
  
  <p><strong>Long comment</strong><br>
  Thanks all for pointing me in the right direction.</p>
  
  <p>Let me explain a bit more. I'm trying to do a faster implementation of <strong><a href="http://en.wikipedia.org/wiki/Hashlife" rel="noreferrer">hashlife</a></strong>, <a href="http://drdobbs.com/high-performance-computing/184406478" rel="noreferrer">see also here</a> or <a href="http://dotat.at/prog/life/hashlife.c" rel="noreferrer">here for simple sourcecode</a></p>
  
  <p>The current record holder is <a href="http://golly.sourceforge.net/" rel="noreferrer">golly</a>, but golly uses a straight translation of Bill Gospher original lisp code (which is brilliant as an algorithm, but not optimized at the micro level at all). Hashlife enables you to calculate a generation in O(log(n)) time.</p>
  
  <p>It does this by using a space/time trade off. And for this reason hashlife needs a lot of memory, gigabytes are not unheard of. In return you can calculate generation 2^128 (340282366920938463463374607431770000000) using generation 2^127 (170141183460469231731687303715880000000) in o(1) time.  </p>
  
  <p>Because hashlife needs to compute hashes for all sub-patterns that occur in a larger pattern, allocation of objects needs to be fast.</p>
  
  <p>Here's the solution I've settled upon:</p>
  
  <p><strong>Allocation optimization</strong><br>
  I allocate one big block of physical memory (user settable) lets say 512MB. Inside this blob I allocate what I call <strong>cheese stacks</strong>. This is a normal stack where I push and pop, but a pop can also be from the middle of the stack. If that happens I mark it on the <code>free</code> list (this is a normal stack). When pushing I check the <code>free</code> list first if nothing is free I push as normal. I'll be using records as advised it looks like the solution with the least amount of overhead.  </p>
  
  <p>Because of the way hashlife works, very little <code>pop</code>ping takes place and a lot of <code>push</code>es. I keep separate stacks for structures of different sizes, making sure to keep memory access aligned on 4/8/16 byte boundaries.  </p>
  
  <p><strong>Other optimizations</strong>  </p>
  
  <ul>
  <li>recursion removal   </li>
  <li>cache optimization</li>
  <li>use of <code>inline</code></li>
  <li>precalculation of hashes (akin to rainbow tables)</li>
  <li>detection of pathological cases and use of fall-back algorithm</li>
  <li>use of GPU</li>
  </ul>