Getting details in parallel may have some benefit, but only after pagination and with a limit. The trick is that it needs to be in the same order. Getting detailed info before paginating would lead to many expensive calls and work against paginating.

There is also ongoing work in this area with #422 that should resolve many issues experienced.

@braydonf makes sense, i should have realized that. Why not parallel after sortAndPaginateCombinedArray? You'd have to process the results in parallel though, as opposed to pushing to detailedArray (to retain sortedness).

It would be possible, but the results would need to be sorted again afterwards. Each transaction has a few queries running in parallel already for populating previous inputs, so the benefit may not be large. Would need to take a look at performance comparisons.

There may also be a benefit to running a batched query.

yep. I was just digging around a bit because i checked an address with a few hundred txs and the response was quite slow. When do you think #422 will land?

@mvayngrib #422 has landed

Code around this area has changed a lot. There is now a 1-to-1 relationship between transaction and rpc call, so I think it's okay to have concurrency here, and have added concurrent requests for getAddressHistory in #449

@braydonf great! closing