listwallettransactions command provides a feature comparable to a select * type of sql query in database ex: Mysql. If the number of transactions are high, it would have a toll on the hardware resource of the underlying system as the buffer required would shoot up. I see this as a general issue which exists in Blockchain and non blockchain systems like a database. In general, in normal systems we tend to provide a limit to the query or provide a count. In the similar fashion, in my opinion I would suggest you to leverage the count and skip model provided by the command api. Now assuming you have 20000 transactions, we can divide the execution to 100 commands for ex:
multichain-cli chain1 listwallettransactions 100 0
multichain-cli chain1 listwallettransactions 100 100
multichain-cli chain1 listwallettransactions 100 200
....
whenever you get an json array response whose size it less than 100, we can stop the loop.
Also by using the command getwalletinfo, we can get the number of total transactions in the wallet at current time: (This could be used to pre-determine the loop)
For example:
{"method":"getwalletinfo","params":[],"id":1,"chain_name":"chain1"}
{
"walletversion" : 60000,
"balance" : 0.00000000,
"txcount" : 153,
"keypoololdest" : 1461150513,
"keypoolsize" : 2
}
Considering the txcount as 153 we can use:
multichain-cli chain1 listwallettransactions 100 0
multichain-cli chain1 listwallettransactions 53 100 or multichain-cli chain1 listwallettransactions 100 100 (The json array response size shall be 53)
Now considering the hardware specs, even if the specs are enhanced, with increase in the number of transactions, the limitations will come. Hence I will think you should be using the count and skip mode.
