Damn, and I thought the bug was that, document is never declared and val is never assigned. :) But yes, waiting for 25s before doing any processing would probably be bad.

I think you just created a new bug :) sp.ElapsedMilliseconds < 250

Shouldn't it be sp.ElapsedMilliseconds > 250 since that is your exit condition?

Another bug is that if your cancellation token is triggered, then the documents that you removed from the queue are lost.

I know this is just a simple example but just in case someone copy and use this code: Maybe new List<RecordMailArgs>(256) before both loops and clearing the list instead of a new one every batch could give you better performance. Not just for the cost of New(); also because Clear does not reset the capacity and prevents autogrouth ( in case you don't use new (Int32) ).

With this implementation and the correct conditions, it's still possible to wait up to 400ms.

Why not compute the remaining time substracting sp.TotalMilliseconds and the initial timeout value ?
I manage to have a stable wait time close to my initial timeout value using different conditions.

Something like

public static IEnumerable<T> TakeDuring<T>(this BlockingCollection<T> collection, int maximumItems, TimeSpan time, CancellationToken cancellationToken)
{
    var sp = Stopwatch.StartNew();
    var count = 0;
    T item;

    while (!cancellationToken.IsCancellationRequested && count < maximumItems)
    {
        var remaining = time - sp.Elapsed;
        if (remaining > TimeSpan.Zero)
        {
            if (collection.TryTake(out item, (int)remaining.TotalMilliseconds, cancellationToken))
            {
                count++;
                yield return item;
            }
        }
        else
            break;
    }

    cancellationToken.ThrowIfCancellationRequested();
}

Another approach for so-called smart batching is no-wait on empty queue. If there's nothing left in the queue, proceed with what you get batched and return to polling the queue. This approach is used by EventStore in its storage service. The same can be seen in the LMAX disruptor pattern and Aeron (messaging protocol). The last two actually obtains the last occupied position (depending on the library it's called differently) and proceed with all the items till this point. With this approach you ensure that small batches will be finished in the amortized time of handling a single batch. In your case, you'll always wait for this and additional timeout.

@Oren so basically the good old difference between throttle and debounce?

http://benalman.com/projects/jquery-throttle-debounce-plugin/

(see the diagrams)