Loading 86 offers takes 4 seconds! Very slow loading of the SELL XMR tab high latency/delay

[slrslr]

Hello, I am unsure if it happened in previous version, I have doubt.
But in current 1.0.17 (I am using Linux .deb file on Debian 12 with KDE), it takes 3-4 seconds to load SELL XMR tab. Other tabs are loading in 1 second.

When I compare the number of offers, indeed slow SELL XMR tab has 86 and BUY XMR only 39.
Regarding active filters, I am displaying everything, and when I enable only offers matching my accounts, it does not improve the loading time.

It is beneficial to have up to date offers, though are these loaded in optimal way? 4 seconds it too high for just 86 offers, imagine the software gets much more users. Possibly tab should be loaded immediately and its content asynchronously (I mean not lock all offers, but load/update each of the offer independently unless too CPU intensive?) while indicating that loading is in progress. If you can not reproduce, please let me know what to do exactly.

After optimization, further thing to consider is some expiring cache, then there should be an easily accessible and visible status area showing: "Updated X seconds ago. Updating..." or similar, so user knows that the view may update in a bit.

[boldsuck]

I also use Linux .deb file on Debian 12 with KDE. I don't have high latency. My RTT to other peers is well under 1000ms (200-800ms).
If you are using Haveno build in Tor then it might be due to Conflux bug.
I use Tor to 0.4.8.13 via externalTor.

I'm trying to upgrade Haveno Tor. Tor-binary and netlayer was easy. I still need to figure out how @preland did it with gradle/verification-metadata.xml 🤔 😵‍💫

[woodser]

I still need to figure out how @preland did it with gradle/verification-metadata.xml 🤔 😵‍💫

Updating the verification metadata is easy, just: ./gradlew --write-verification-metadata sha256