Using fullCount will make a query run further even if the request number of documents have been reached. So it will naturally be slower than when omitting fullCount altogether.
Using fullCount may be slower or faster than when using a separate query just for counting. This depends on whether the fullCount query contains complex calculations that may be omitted in an extra counting query.
For example,

FOR doc IN collection
  LIMIT 0, 40
  RETURN doc

with fullCount will likely be slower than the same query with fullCount turned off and an extra couting query. The reason here is that counting the number of documents in a collection is fast and does not need to enumerate them individually.
Another example:

FOR doc IN collection
  LET subs = (FOR sub IN collection2 FILTER sub.attr == doc._key RETURN sub)
  LIMIT 0,40 
  RETURN { doc, subs }

In this example, the fullCount variant of the query will be much more expensive than the original query without fullCount and a separate counting query that can omit the subquery.

Can you provide an example of the query that is particularly slow with fullCount, plus the number of documents in the respective collections.

We should explain this here too: https://docs.arangodb.com/3.3/AQL/ExecutionAndPerformance/QueryStatistics.html

@dothebart: go ahead!

my query is similar to

for log in logs sort log.date limit 0, 20 return log

there are about 500k docs. It runs in about 200ms with full count on, 2ms with full count off.

fwiw to get the count manually im adding this to the same query COLLECT WITH COUNT INTO length RETURN length

@ldap4life : ok, if there is a sorted index present on the date attribute in the logs collection, the non-fullCount query will execute almost instantly. It will only process 20 documents in index order and is done then.
The fullCount variant of the query will return 20 documents in index order, but it will iterate over the remaining 499980 documents in the index for counting them. So it will have to do a lot more work, especially in the RocksDB engine, where index iteration may (or may not) cause disk I/O.

If your original query does not contain any filters, the counting is probably most efficiently done by using just RETURN COUNT(logs). This will use an optimized code path that simply returns the number of documents in the collection without even looking at any document.

Could this be detected by optimizer ? For example, if a query has no FILTER statement, return collection size as fullCount instead of iterating over every document ?