libera #monero-dev

6 Feb 2024

Official repo: github.com/monero-project/monero || Don’t ask to ask, just ask:) || Monero GUI dev is at #monero-gui || Monero website dev is at #monero-site || Non-dev questions -> #monero, please || No fork help, you’re on your own

• 11:59
  m-relay
  <s​needlewoods_xmr:matrix.org> will dm you the details, everything else I tested manually with monero-wallet-cli worked as expected
• 20:48
  m-relay
  <o​nefuryone:matrix.org> I hate the government I hate big tech...I hate cbdcs. Oh and I hate binance. I love Monero...I hold Monero...am I in the right place?
• 21:03
  Inge
  nope, try #monero
• 21:26
  xFFFC0000
  paste.debian.net/1306538 we spend unbelievable amount of time in get_difficulty_for_next_block
• 21:30
  moneromoooo
  This paste does not show evidence for that claim.
• 21:36
  xFFFC0000
  That is output from perf for two node syncing locally (one fully sync, one started blank). Will upload all of it in few hours. Got tired went outside.
• 21:36
  moneromoooo
  Yes, but you need to show what's *up* from this. Your paste could be the same if the function was fast or slow.
• 22:28
  sech1
  Makes sense, considering that you need to poke lmdb 720 times to get all DIFFICULTY_WINDOW blocks' data
• 22:28
  sech1
  for each new block
• 22:28
  sech1
  get_block_cumulative_difficulty x 720, get_block_timestamp x 720 - that makes 1440 lmdb transactions
• 22:30
  sech1
  it should reduce it to 2 lmdb transactions per block if you request them sequentially
• 22:33
  sech1
  moneromoooo did you ever get this triggered? github.com/monero-project/monero/bl…cryptonote_core/blockchain.cpp#L993
• 22:33
  sech1
  using std::stringstream all the time to do logging there can slow it down too
• 22:34
  selsta
  yes, this was triggered a couple times but we fixed it, since then not anymore