Sigops stands for signature operations. Bitcoin transactions can contain multiple signature operations depending on the complexity of the script, P2SH output for example could allow you to pad to a fairly high number of sigops but keep in mind that current standardness limits keeps it under 15. Current consensus limits sets it at 80,000 sigops per block.
I saw your topic a few days ago but unfortunately I couldn't come up with any concrete numbers so I didn't comment on it. That being said, here is what I've experimented with so far, do take it with a grain of salt though.
I've run two instances of Bitcoin Core (0.21.0), and the results were fairly similar, this is from my run which I downloaded from scratch. From what I've observed, the timing will vary significantly if you choose to select assumevalid.
- Connect postprocess: 0.00ms [1.67s (111.43ms/blk)]
- Connect block: 8429.91ms [341.49s (22766.07ms/blk)]
- Load block from disk: 5.00ms [0.01s]
- Sanity checks: 1.00ms [0.00s (0.13ms/blk)]
- Fork checks: 0.00ms [0.00s (0.00ms/blk)]
- Connect 2075 transactions: 10465.00ms (5.043ms/tx, 1.571ms/txin) [350.14s (21883.62ms/blk)]
- Verify 6661 txins: 10465.00ms (1.571ms/txin) [350.14s (21883.75ms/blk)]
- Index writing: 3.00ms [0.06s (3.84ms/blk)]
- Callbacks: 0.00ms [0.00s (0.06ms/blk)]
- Connect total: 10470.01ms [350.21s (21888.03ms/blk)]
- Flush: 4.00ms [0.08s (5.00ms/blk)]
- Writing chainstate: 0.00ms [0.00s (0.00ms/blk)]
I think that the IDB download would be far more accurate considering that the transactions are not relayed first to the node but it's verified with the received block. The former would probably have majority of the transactions being in the mempool first and would have been verified already. The numbers can and will be misleading. A single P2SH input can contain multiple Sigops and I can't find a way to benchmark individual transactions or transactions with a single sigops only.
The results would vary quite wildly across different systems, considering the fact that the process is not purely CPU bound but would also involve your RAM with the UTXO set being stored on it, depends on how much dbcache you have. You can try running the secp256k1 benchmark as well:
https://github.com/bitcoin-core/secp256k1.