Slow mempool filling on Bitcoin Core node

So, I've noticed something after firing up my Bitcoin Core node. It often takes ages for the mempool to fill up, even when I'm linked to a bunch of outgoing peers. Like, sometimes it feels like I’m waiting for almost an hour before it starts grabbing mempool transactions. It’s kinda frustrating, honestly. I really wish those transactions would load up quicker.

Are you measuring this time after your node catches up with the network and syncs? Because if you are syncing and your UTXO set is not up to date, you are not capable of verifying newer transactions so your mempool is not supposed to fill up yet. As far as I can tell the following is the code responsible for it; if your node is at least 24 hours behind it is considered in the IBD state so any tx messages that it receives (and supposed to place in its mempool) are ignored. https://github.com/bitcoin/bitcoin/blob/bf1b6383dbbfdd0c96a161d4693a48bf3a6b6150/src/net_processing.cpp#L4292

I was actually counting from the time Bitcoin core starts finding and connecting to other peers via DNS. debug.log usually has this message that says "waiting for 6000 seconds before querying DNS seeds", which is what I was referring to. That doesn't really make any sense to do that though. Sure the node will not have a way to verify that mempool transactions are valid, while it is doing IBD, but what is stopping it from just collecting the top few vMB (like the default 300vMB) of transactions, and then only verify those transactions after the IBD is done and discard or keep them accordingly?

You can do so, if you really want. The software is just not written in that way. There are many ways to optimize things, for example you could download things backwards, and start from the last block. Then, initially, your node would have SPV-level, and it would keep downloading things, proving that everything is correct, and is more and more deeply confirmed. And finally, you could reach the Genesis Block, and be sure that everything is valid. The only reason why it is not the case, is that nobody implemented it in that way, and you have only full nodes, or SPV nodes, and you don't have for example "SPV nodes, which are gradually converted into full nodes". Also, in the same way, technically you could have things like "unprune blocks", which could allow going from 1 GB last blocks, for example into 100 GB last blocks, without waiting for 99 GB new blocks, but you simply don't have such features, because nobody wrote it in that way (even though it is possible to do so).

It requires a lot of developers' work to write a ton of code handling these cases and rewriting a lot of the logic that makes your node work. For example when you receive a tx, it is handled as a peer sending you that tx and that peer is going to be evaluated so that you can "ban" it in case it was malicious and were sending you invalid txs. The devs have to re-write the code to handle this case and skip the peer score logic. They'll also have to write additional logic to skip a bunch of your mempool preference such as minimum fee since your node has no idea what fee they're paying (UTXO set not yet up-to-date). It's just easier to ignore the tx when your node is during IBD.