Wallet filter is always in memory. When wallet db starts, it loads all relevant information that it needs to track from the database: address hashes, outpoint hashes and name hashes. This is walletdb specific, not wallet one. This can grow in size quickly if the wallet is active/old enough. To speed up start up time of the wallet we could, after every batch write, also write filter to either disk or the database (this makes it easier to make sure there are no race issues). On load if the file exists, we load filter from the file instead of the looping through all WID mappings of above mentioned hashes.
Also worth investigating the number of items, after which having filter makes no more sense and returns high % of false positives. At certain point it's simpler to just grab the full block every time. For those settings wallet can just track the number of items filter indexes and use those stats to decide if the filter should be used.
Wallet filter is always in memory. When wallet db starts, it loads all relevant information that it needs to track from the database: address hashes, outpoint hashes and name hashes. This is walletdb specific, not wallet one. This can grow in size quickly if the wallet is active/old enough. To speed up start up time of the wallet we could, after every batch write, also write filter to either disk or the database (this makes it easier to make sure there are no race issues). On load if the file exists, we load filter from the file instead of the looping through all WID mappings of above mentioned hashes.
Also worth investigating the number of items, after which having filter makes no more sense and returns high % of false positives. At certain point it's simpler to just grab the full block every time. For those settings wallet can just track the number of items filter indexes and use those stats to decide if the filter should be used.