The library switched to using the product of pairing operation internally in bgls, where the product of pairings is currently implemented as doing the product in parallel, in lieu of a faster algorithm not yet being implemented in the upstream libraries. However, this means with the current setup, all the hashes must complete, before the product has begun to be taken. This is sub-ideal. There are two different methods I can see of getting the old speed back. We can add a second method, for product of pairing with hashing, so the concurrency is re-obtained, and we can add batching, so it doesn't have to wait for all the hashes to compute in order to start a product of pairings. I suspect that both of these solutions ought to be implemented here.
The library switched to using the product of pairing operation internally in bgls, where the product of pairings is currently implemented as doing the product in parallel, in lieu of a faster algorithm not yet being implemented in the upstream libraries. However, this means with the current setup, all the hashes must complete, before the product has begun to be taken. This is sub-ideal. There are two different methods I can see of getting the old speed back. We can add a second method, for product of pairing with hashing, so the concurrency is re-obtained, and we can add batching, so it doesn't have to wait for all the hashes to compute in order to start a product of pairings. I suspect that both of these solutions ought to be implemented here.