好吧,我提点意见。
个人感觉vector不行,可能根本没必要加从数据库取数据存到vector那一步。速度慢,吃内存。用BTS资产做个分红测试,截个CPU图看看?
我注意到了,
但我先预先申请足够的内存。所以vector和数组效率相当。
性能还可以,我在本地测试的
给1000个账号分红,用时少于1s
给11000个账号分红,用时间大于3s
这个感觉优化空间还很大。处理时间大于500ms时witness就不会出块了,如果每个witness都处理不过来,等于网络挂掉。只要有一个 witness够强,能处理过来,就还好,会丢块,但至少不会挂掉。
可以预先计算下,有多少个账户分红,如果超过一定数量,直接拒绝处理,需要使用优化过版本。这个数量由一个性能测试给出来,写死在代码里。但这个预先计算也要先做好性能测试和优化,别直接跑挂了。
另外可以加个规则:每个块最多跑一个分红交易,多的不受理。甚至,发现有分红交易,其他交易都不处理。或者只在“维护块”时才处理分红交易,这样处理时间就相对充裕一点。
考虑 A股股东一般在几万左右,
初期的BTS的资产 股东一般在 几百左右,性能够用了
将来如果一个资产真在几万甚至几十万个股东,有两个方便可以改进
1.witness当让需要更好的电脑,
2.执行操作时候采取异步, 先adjust 发分红者的余额,就可以打包交易广播了,然后在慢慢调整股东余额。这样不会影响打包速度。
异步操作的思路可以,但是需要在处理下个块,或者本块下一个操作前完成,否则,如果下个操作需要引用分红操作的结果数据,就傻了,会导致卡死或者数据不一致(分叉)。这个可能涉及整个架构的调整,方向没问题,但预计工程量不小。
以上供参考。