So you think Sitecore fast query is faster than 'normal' Sitecore query? Not so fast. Let me act as a myth buster here.
A Sitecore query is evaluated against Sitecore items, and allow you to query items in the tree that meet certain criteria. In order to execute that query Sitecore may look at items in its cache, but if they are not there, it will get them from database. On the other hand, a fast query is always translated into SQL statements. It therefore bypasses caches, it always goes to the database.
This brings some advantages particularly when running in a cold installation where the items are not in the cache. When using a non-fast Sitecore Query the items will get added to the cache (that takes time) and the query run at an application level. The fast query simply gets resolved on the database, Sitecore gets a list of IDs, for the result items and then retrieves those from cache, or database in the normal fashion.
This also brings a disadvantage, when the application has already got most items in cache, it is already warmed up, you are bypassing the cache and going directly to the database. This can be slower than just using the cached items.
A secondary limitation is that not all Sitecore query expressions can be translated to SQL statements, sometimes Sitecore needs to run application level logic to resolve the query. That's why fast query only supports a subset of the language (check the documentation for the full information, but in essence, it only support basic axes, does not support contains, ignores standard values, etc.).
So a fast query might be faster con a cold installation, but it's likely not to be faster on a warmed app Sitecore.
In addition, fast query does not scale as well as the traditional query. Why? Because it will be affected by the growth of the database, whereas the non-fast version will fly using information in cache (as long as you have enough memory and caches are configured correctly).
Don't be misled by the prefix "fast"; it might actually be slower.
You should not use Sitecore query to do complex things, so if your query does not perform, do not use fast, use Content Search instead. This will query an index, and perform much better.
To further illustrate the point, let me show you a query which returns all currently locked items:
fast:/sitecore//*[@__Lock!='' and @__Lock!='<r />']
When I run this query in a Sitecore 8.1 with just under 9000 items (in my not very fast dual core i7) it takes around between 900 milliseconds and 1 second.
The non-fast version of this query
/sitecore//*[@__Lock!='' and @__Lock!='<r />']
takes close to 4 seconds when I run on a cold installation. Subsequent runs take around 350 milliseconds.
The same operation done through Content Search using the LinqScratchPad takes between 5 and 7 milliseconds. Take your pick...