Answers.Body: <p>If you turn on debug mode in your config file, and then create an ultra simple template with just these code options in it, you should be able to look at the logs in the console. It should tell you the query time in milliseconds. I've never used reference tags; however, I  would suspect that the performance difference is minimal. I personally would opt for the second method, so that <code>entry.title</code> is not hard coded.</p>
  
  <p>As a side note, you can also wrap the code in <code>{% cache %}... {% endcache %}</code> tags to further increase performance either way.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-02-02T02:22:03.370Z
Answers.Text: If you needed the titles to be dynamic, you could parse `{entry:3666:title}` as well. Thanks for the debugger idea.
Answers.UserDisplayName: Michael Rog
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-02-01T18:56:43.877Z
Answers.LastActivityDate: 2015-02-01T19:02:27.830Z
Answers.LastEditDate: 2015-02-01T19:02:27.830Z
Answers.UserDisplayName: Douglas McDonald
Body: <p>I have a small menu of fixed entries that forms a sub-nav on a site.</p>
  
  <p>I'm currently using Reference Tag parsing to grab links to these entries:</p>
  
  <pre><code>&lt;li&gt;&lt;a href="{{ '{entry:3666:url}' | parseRefs }}"&gt;Help&lt;/a&gt;&lt;/li&gt;
  &lt;li&gt;&lt;a href="{{ '{entry:3667:url}' | parseRefs }}"&gt;Donate&lt;/a&gt;&lt;/li&gt;
  &lt;li&gt;&lt;a href="{{ '{entry:3668:url}' | parseRefs }}"&gt;About Us&lt;/a&gt;&lt;/li&gt;
  </code></pre>
  
  <p>I think this is a really clean/readable way to create this sub-nav, but I'm not sure about the performance implications. I could accomplish the same thing by calling up an ElementCriteriaModel using a fixedOrder:</p>
  
  <pre><code>{% entries = craft.entries.id(3666, 3667, 3668).fixedOrder(true) %}
  {% for entry in entries %}
      &lt;li&gt;&lt;a href="{{ entry.url }}"&gt;{{ entry.title }}&lt;/a&gt;&lt;/li&gt;
  {% endfor %}
  </code></pre>
  
  <p>Does anybody know if one option is significantly performant over the other?</p>
  
  <p>(I wouldn't be surprised if Craft is intelligently caching its entry data queries, such that it wouldn't have to create a new element query each time a Reference Tag is encountered/parsed... but I'm not knowledgable enough to say.)</p>
  
  <p><em>Other SE questions about best-practice for linking to single entries:</em></p>
  
  <ul>
  <li><em><a href="https://craftcms.stackexchange.com/questions/2640/whats-the-best-way-to-link-to-an-entry-in-a-template">What&#39;s the best way to link to an entry in a template?</a></em></li>
  <li><em><a href="https://craftcms.stackexchange.com/questions/769/how-do-i-create-a-link-to-an-entry-using-entrys-id">How do I create a link to an entry using entry&#39;s id?</a></em></li>
  </ul>
  
Tags: <entries><navigation><performance><best-practice><reference-tags>
Title: Linking to specific entries in Twig: How performant is Reference Tags parsing?
ThreadText: # Linking to specific entries in Twig: How performant is Reference Tags parsing?
  
  (Asked by: username_0 on 2015-02-01)
  
  I have a small menu of fixed entries that forms a sub-nav on a site.
  
  I'm currently using Reference Tag parsing to grab links to these entries:
  
  ```
  <li><a href="{{ '{entry:3666:url}' | parseRefs }}">Help</a></li>
  <li><a href="{{ '{entry:3667:url}' | parseRefs }}">Donate</a></li>
  <li><a href="{{ '{entry:3668:url}' | parseRefs }}">About Us</a></li>
  
  ```
  
  I think this is a really clean/readable way to create this sub-nav, but I'm not sure about the performance implications. I could accomplish the same thing by calling up an ElementCriteriaModel using a fixedOrder:
  
  ```
  {% entries = craft.entries.id(3666, 3667, 3668).fixedOrder(true) %}
  {% for entry in entries %}
      <li><a href="{{ entry.url }}">{{ entry.title }}</a></li>
  {% endfor %}
  
  ```
  
  Does anybody know if one option is significantly performant over the other?
  
  (I wouldn't be surprised if Craft is intelligently caching its entry data queries, such that it wouldn't have to create a new element query each time a Reference Tag is encountered/parsed... but I'm not knowledgable enough to say.)
  
  *Other SE questions about best-practice for linking to single entries:*
  
  * *[What's the best way to link to an entry in a template?](https://craftcms.stackexchange.com/questions/2640/whats-the-best-way-to-link-to-an-entry-in-a-template)*
  * *[How do I create a link to an entry using entry's id?](https://craftcms.stackexchange.com/questions/769/how-do-i-create-a-link-to-an-entry-using-entrys-id)*
  
  **Tags:** entries, navigation, performance, best-practice, reference-tags
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2015-02-01. Score: 1
  
  If you turn on debug mode in your config file, and then create an ultra simple template with just these code options in it, you should be able to look at the logs in the console. It should tell you the query time in milliseconds. I've never used reference tags; however, I would suspect that the performance difference is minimal. I personally would opt for the second method, so that `entry.title` is not hard coded.
  
  As a side note, you can also wrap the code in `{% cache %}... {% endcache %}` tags to further increase performance either way.
  
  > **Comments:**
  > **username_0**: If you needed the titles to be dynamic, you could parse `{entry:3666:title}` as well. Thanks for the debugger idea.  
  
  ---
  
  