[bisq-network/bisq] Cache results in account witness domain (#4953)

chimp1984 notifications at github.com
Tue Dec 15 20:29:08 CET 2020


Here are results from performance tests (based on live network data):

I used a loop for 5 iterations over each offer. For findWitness 10000 iterations.

Version of that PR:
652 offers. 6520000 calls of accountAgeWitnessService.findWitness(offer) took 783 ms  (84% to master)
652 offers. 3260 calls of accountAgeWitnessService.getSignState(accountAgeWitness) took 2063 ms (71% to master)
652 offers. 3260 calls of accountAgeWitnessService.getWitnessSignAge(accountAgeWitness, now) took 4094 ms (78 %to master)
652 offers. 3260 calls of accountAgeWitnessService.getAccountAge(accountAgeWitness, now) took 4094 ms (78% to master)
652 offers. 3260 calls of signedWitnessService.getSignedWitnessSet(accountAgeWitness) took 4095 ms (74% to master) 
652 offers. 3260 calls of signedWitnessService.getWitnessDateList(accountAgeWitness) took 4096 ms (70% to master) 

Master version:
653 offers. 6530000 calls of accountAgeWitnessService.findWitness(offer) took 924 ms 
653 offers. 3265 calls of accountAgeWitnessService.getSignState(accountAgeWitness) took 2873 ms 
653 offers. 3265 calls of accountAgeWitnessService.getWitnessSignAge(accountAgeWitness, now) took 5226 ms 
653 offers. 3265 calls of accountAgeWitnessService.getAccountAge(accountAgeWitness, now) took 5226 ms 
653 offers. 3265 calls of signedWitnessService.getSignedWitnessSet(accountAgeWitness) took 5501 ms 
653 offers. 3265 calls of signedWitnessService.getWitnessDateList(accountAgeWitness) took 5788 ms 

I expecte that the findWitness call is more expensive but seems thats not the bottleneck but some other calls inside the tested methods.
The optimization was mainly focussed on findWitness. It still is about a 20-30% improvement.
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.

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.... 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/bisq/pull/4953#issuecomment-745514854
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20201215/b098a208/attachment.htm>


More information about the bisq-github mailing list