<p></p>
<p>Here are results from performance tests (based on live network data):</p>
<p>I used a loop for 5 iterations over each offer. For findWitness 10000 iterations.</p>
<p>Version of that PR:<br>
652 offers. 6520000 calls of accountAgeWitnessService.findWitness(offer) took 783 ms  (84% to master)<br>
652 offers. 3260 calls of accountAgeWitnessService.getSignState(accountAgeWitness) took 2063 ms (71% to master)<br>
652 offers. 3260 calls of accountAgeWitnessService.getWitnessSignAge(accountAgeWitness, now) took 4094 ms (78 %to master)<br>
652 offers. 3260 calls of accountAgeWitnessService.getAccountAge(accountAgeWitness, now) took 4094 ms (78% to master)<br>
652 offers. 3260 calls of signedWitnessService.getSignedWitnessSet(accountAgeWitness) took 4095 ms (74% to master)<br>
652 offers. 3260 calls of signedWitnessService.getWitnessDateList(accountAgeWitness) took 4096 ms (70% to master)</p>
<p>Master version:<br>
653 offers. 6530000 calls of accountAgeWitnessService.findWitness(offer) took 924 ms<br>
653 offers. 3265 calls of accountAgeWitnessService.getSignState(accountAgeWitness) took 2873 ms<br>
653 offers. 3265 calls of accountAgeWitnessService.getWitnessSignAge(accountAgeWitness, now) took 5226 ms<br>
653 offers. 3265 calls of accountAgeWitnessService.getAccountAge(accountAgeWitness, now) took 5226 ms<br>
653 offers. 3265 calls of signedWitnessService.getSignedWitnessSet(accountAgeWitness) took 5501 ms<br>
653 offers. 3265 calls of signedWitnessService.getWitnessDateList(accountAgeWitness) took 5788 ms</p>
<p>I expecte that the findWitness call is more expensive but seems thats not the bottleneck but some other calls inside the tested methods.<br>
The optimization was mainly focussed on findWitness. It still is about a 20-30% improvement.<br>
There are about 3000-5000 signedWitnessService.getSignedWitnessSet in normal user activity after a few minutes which accumulates to about 6-10 sec. cpu time in all.</p>
<p>As its a bit risky domain I have no strong opinion about to merge that PR or close it and delay for a later more broad investigation and improvement. Up to maintainers....</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/bisq-network/bisq/pull/4953#issuecomment-745514854">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AJFFTNXBFY5YGSJDE5K6E2LSU62IJANCNFSM4U32MFNA">unsubscribe</a>.<img src="https://github.com/notifications/beacon/AJFFTNUJ66NT2CTMQL6GNT3SU62IJA5CNFSM4U32MFNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOFRX2OZQ.gif" height="1" width="1" alt="" /></p>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/bisq-network/bisq/pull/4953#issuecomment-745514854",
"url": "https://github.com/bisq-network/bisq/pull/4953#issuecomment-745514854",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>