Is `query_posts` really slower than secondary query?

Question

I know the main query is fast, since it gets data after parsing the URL and after WP_Query has been instantiated. We are in OO PHP.

But is query_posts really slower than some secondary query that happens in a template for instance with get_posts, or native that you call with

// WP_Query arguments
$args = array (
);

// The Query
$query = new WP_Query( $args );

Answer 1

You ask:

is query_posts really slower than some secondary query...

The fact is that if you're calling query_posts() from a theme then it already is a secondary query. WordPress has already queried the database once to get a certain page then it hits your query_posts() function and queries the database again creating a second query and overwriting the original request / data.

From a speed perspective you're not going to notice any difference. The query_posts() functions uses WP_Query() and takes microseconds to overwrite some global variables. The biggest overhead will come from you having to normalize your data and make up for any niche issues with pagination.

Simply put, it's all around inefficient. So, while there may not be a "big red button" that says "Don't press here!" it's pretty much implied that it shouldn't be pressed. It's not big and red but The Codex specifically states:

Note: This function isn't meant to be used by plugins or themes.

If you want to be efficient and need to override the main query - use pre_get_posts which will modify the query parameters before it calls it from the database which saves an entire database call ( in that we don't need a secondary query ).

Answer 2

In general,

• the query performed on the homepage,

• query_posts( 'posts_per_page=get_option( 'posts_per_page' ) and

• $q = new WP_Query( 'posts_per_page=get_option( 'posts_per_page' )

should have the same exact performance with very very little to no difference between them as all of the above are exactly the same by default (that is, have the same query arguments by default). This is because all of these queries uses the WP_Query class to run build and run db queries to return the queried posts. get_posts() is a bit faster although it also uses WP_Query. The big difference is that get_posts passes no_found_rows=true to WP_Query which legally breaks pagination.

What is true, the main query (primary query) runs on each and every page load according to the exact page being loaded. Removing the main loop and replacing it with a secondary query (either query_posts(), WP_Query or get_posts()) is what is referred to as making the page slow. This is because you are doing the same work twice. As I said, the main query runs regardless, so you have already queried the db for posts, and replacing the main loop with a secondary query queries the db again.

Apart from issues created with pagination and other crappy issues, this is why one should never replace the main loop from the main query with a secondary one. I have done an extensive post on this which you can read here. To alter the main query, always use pre_get_posts as it alters the query vars before the WP_Query class builds and runs the SQL query. There are also other filters (post clause filters) available in WP_Query which you can use to directly alter the SQL query

What makes query_posts bad is that it alters the main query object on which many functions rely as query_posts does the following

$wp_query = new WP_Query()

and it also alters the conditional tags. For a full explanation, you can read my answer here. A normal WP_Query does not do that