Per recent conversations about needing to support more potential winning bidders (up to 10,000 as opposed to the current limit of around 400), we need to develop a standalone EMPA contract that avoids several costly operations:
We do not create an array of winning bids in memory (memory costs increase as you use more of it) and send between contracts.
We only perform a static number of transfers in the settle function (e.g. seller payment/refund, curator, partial bid fill). As a result, most bidders (win or lose) must claim their payout/refund after the auction is settled.
Reduce the number of variables stored (remove abstractions not relevant in a single auction type contract) and pack them more efficiently, including making assumptions about the size of amount values (12 bytes, same as Gnosis Auction).
Switch out priority queue implementation for a more scalable binary heap style implementation. This can be done since we only iterate through the queue once and do not need it to be sorted in place.
The standalone EMPA refactor referenced in #48 solves various problems with the current implementation, but departs from our general modular framework. Ideally, we would port the necessary changes back to a module-based version that exists within the singleton AuctionHouse. This requires some additional refactoring of the Auction module abstract, Auction House, and writing a new EMPA Module (EMPAM).
To determine which version to use, we should assess how much overhead the module version adds (due to greater generality of the abstractions and probably a few extra external calls) and use that to determine if the module version is efficient enough (which is preferred).
Per recent conversations about needing to support more potential winning bidders (up to 10,000 as opposed to the current limit of around 400), we need to develop a standalone EMPA contract that avoids several costly operations:
The standalone EMPA refactor referenced in #48 solves various problems with the current implementation, but departs from our general modular framework. Ideally, we would port the necessary changes back to a module-based version that exists within the singleton AuctionHouse. This requires some additional refactoring of the Auction module abstract, Auction House, and writing a new EMPA Module (EMPAM).
To determine which version to use, we should assess how much overhead the module version adds (due to greater generality of the abstractions and probably a few extra external calls) and use that to determine if the module version is efficient enough (which is preferred).