I think that now I understand what you are trying to do. When you run a custom query with WP_Query and set the limit to get only 5 posts per page, only 5 posts will be retrieved by the query and that query will only hold 5 posts, BUT for the sake of pagination, WP_Query still runs through the whole database and counts all the posts that matches the criteria of the query.

That can be seen when you look at the $found_posts and $max_num_pages properties of the query. Lets take an example:

You have 20 posts belonging to the default post type post. You only need the latest 5 posts without pagination. Your query looks like this

$q = new WP_Query( 'posts_per_page=5' );

• var_dump( $q->posts ) will give you the latest 5 posts as expected
• echo $q->found_posts will give you 20
• echo $q->max_num_pages will give you 4

The impact of this extra work is minimal on sites with only a few posts, but this can gt expensive if you are running a site with hundreds or thousands of posts. This is a waste of resources if you are only ever going to need the 5 latest posts

There is an undocumented parameter called no_found_rows which uses boolean values which you can use to make your query bail after it found the 5 posts you need. This will force WP_Query not to look for any more posts mathing the criteria after it has retrieved the amount of posts queried. This parameter is already build into get_posts, that is why get_posts is a bit faster than WP_Query although get_posts uses WP_Query

Conclusion

In conclusion, if you are not going to use pagination on a query, it is always wise to 'no_found_rows=true' in your query to speed things up and to save on wasting resources.