While investigating dask/distributed#8958, I noticed this:

<Task None concrete(<Task None _identity_cast(<Task None _identity_cast(<Task None _identity_cast(<Task None _identity_cast(<Task None _identity_cast(Alias(('getitem-f7fd4f245dfedafeb33a2841a9c414ca', 2, 3, 19, 5, 0)), typ=<class 'list'>)>, <Task None _identity_cast(Alias(('getitem-f7fd4f245dfedafeb33a2841a9c414ca', 2, 3, 19, 5.9, 0)), typ=<class 'list'>)>, typ=<class 'list'>)>, typ=<class 'list'>)>, typ=<class 'list'>)>, typ=<class 'list'>)>)>=

Basically, the embedding of keys into nested data structures creates a large overhead of task objects. For the workload I investigated, this appears to have contributed up to 50% of all tasks. (Take that number with a grain of salt.)

We should avoid using these nested data structures for keys entirely. In array-code, I've identified the usage of concrete (the example above) as a culprit that can be trivially removed. However, concatenate3 and related functions are other culprits that require a bit more rewriting.