title: UITableView dequeueReusableCellWithIdentifier Theory
body: <p>When apple developed the <code>UITableView</code> for the first iPhone they had a problem in performance when scrolling through it. Then one clever engineer discovered that the cause of this was that allocation of objects comes with a price, so he came up with a way to reuse cells.</p>
  
  <blockquote>
    <p>"Object allocation has a performance cost, especially if the allocation has to happen repeatedly over a short period—say, when the
    user scrolls a table view. If you reuse cells instead of allocating
    new ones, you greatly enhance table-view performance."</p>
    
    <p><em>Source: iOS Reference Library</em></p>
  </blockquote>
  
  <p>To reuse a cell you use:</p>
  
  <pre><code>UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
  </code></pre>
  
  <p>Now, what I am wondering is, what actually happens here? Does it look in the TableView if there is a cell with that identifier and just returns that one? Well yea duh, but if it sends a reference instead of allocating and I have a table view with let's say 4 cells with the same identifier all visible. How can it multiply itself into four instances without allocating?</p>
  
  <p>I want to know this because I am building a calendar type component and all the cells have the same structure only the text within changes. So if I could somehow reuse my cells instead of allocating I think I might get a better performance.</p>
  
  <p>My own theory is that it allocates the four cells (simply because it has too). When a cell disappears from the screen it will be put in the TableView reuse queue. When a new cell is needed it looks in the que if a cell with the same identifier is available, it invokes <code>prepareForReuse</code> method on that cell and it removes itself from the queue.</p>