I think this is the price we have to pay.

I think we're going to want to move away from taking threads as inputs in net/ classes (Though we'll need the one for the cache, as that's a SingleThreadedTaskRunner instead of a SequencedTaskRunner)

Once we get DNS and the SimpleCache using the scheduler instead of worker pools, that also means Cronet will potentially be keeping around fewer threads as well.

Thanks for filing the size increase!

I would say this is a WontFix, but adding the TaskScheduler team so they are aware of the binary size increase and can comment.

The switch to TaskScheduler was inevitable; whether in my CL, or a subsequent one to tackle say https://bugs.chromium.org/p/chromium/issues/detail?id=659191 in //net code.

The binary increase this introduces will to a (probably small) degree be offset in the future when supporting code like WorkerPool can be deleted.

The justification for this increase is hopefully as Matt suggests, that we will see runtime resource reduction (memory and/or threads) in the future.

Right we saw this when enabling in renderers a while back but it was quickly offset by enabling SequencedWorkerPool redirection (which makes its API merely a front that forwards to TaskScheduler. The redirection is about to be default everywhere (if SequencedWorkerPool usage isn't completely phased out first), in the meantime you can use SequencedWorkerPool::EnableWithRedirectionToTaskSchedulerForProcess() in your main.

Or wait thought this was memory, but looks like binary size? Why would a runtime thing make the library larger? No more LTO suppression of the TaskScheduler code?

The TaskScheduler wasn't being instantiated on Cronet, so now that we're doing that, we saw a binary size increase.  Eric and I were just pointing out we may see some reduction in runtime memory usage as a result of the change, since (once everything uses TaskScheduler), we'll probably be keeping around fewer threads, as both the cache and DNS resolver use worker pools.

Oh, sorry, misunderstood your confusion.  Correct, if we never instantiated the TaskScheduler, LTO presumably eliminated the code.

Thanks everyone for the context. The potential runtime resource savings make sense to me and it looks like the binary size increase is inevitable and might be mitigated once we completely switch over to TaskScheduler. 
I will WontFix this one.