2017-06-08 IRC 会议摘要

• 本周日志链接
• 会议记录由 meetbot 生成

主要议题

• 优化：减少区块哈希计算次数
• UI 与 pertxout 升级交互
• crc32 leveldb 1.20

优化：减少区块哈希计算次数

背景

当前在块尖处哈希头信息大约 6 次。Jtimon 提交了 PR #10339 来改善这种情况。Wumpus 做了一些基准测试，结果减少了 26% 的哈希运算。

评论

Gmaxwell 建议在块对象中缓存哈希值，但 Sipa 更倾向于这种解决方案。他认为，向特定验证函数添加更多参数，比改变原始数据结构侵入性更小。Wumpus 认为，传递额外参数比扩展原始数据结构更容易理解，但是缓存总是存在一定风险和错误。Wumpus 认为，如果性能上不值得，我们就不应该做任何操作。

Morcos 怀疑，这种加速是否值得牺牲代码变得稍微复杂/繁琐。Gmaxwell 提出了这个问题，因为重复哈希位于块传播延迟关键路径上，可能会造成毫秒级的延迟。Codeshark 宁愿牺牲一点性能，也要获得更好的架构。

Jtimon 认为，不同意这个概念的人应该早点说清楚。

结论

• 在会议结束后和 PR #10339 上进一步讨论。

UI 与 pertxout 升级交互

背景

PR #10195 将链状态数据库及其缓存从每个交易模型切换到每个交易输出模型，需要对数据库进行升级，这在性能良好的硬件上可能需要几分钟，或者在其他地方可能需要更长时间。Sipa 认为，这需要一些 GUI 交互，让用户清楚地了解正在发生的事情。

评论

Jonasschnelli 建议使用 uiInterface.Progress，但是这不能中断进程。用户可能希望将升级过程推迟到另一个时间。

Luke-jr 怀疑，如果崩溃、运行旧版本，然后再次运行新版本，会发生什么。Gmaxwell 认为，旧版本会提示数据库损坏并停止，但他没有测试过。他确实认为应该处理这种情况。

返回旧版本需要重新索引，而修剪过的节点无法做到这一点。发布说明中应该有明确的警告。

Sipa 指出，可以进行一个微不足道的更改，以确保旧版本将其视为一个空数据库。一种方法是创建一个新的数据库，但这在升级期间需要双倍的磁盘存储空间。微不足道的方法是将最佳区块哈希记录设置为无效值。

结论

• Jonasschnelli 将致力于记录过程，类似于 VerifyDB。
• 监控升级过程中的磁盘使用情况并进行更多测试。根据这些结果继续讨论。

crc32 leveldb 1.20

背景

最新版本的 levelDB 为英特尔实现了硬件加速的 crc32，用于计算校验和。

评论

Sipa 非常不喜欢 levelDB 开发人员使用的方法，这需要使用不同的标志编译单独的对象，并且他们调用新的对象，而不知道 CPU 是否支持它。Wumpus 和 Gmaxwell 指出，使用特殊标志编译单独的对象是标准的正确做法，但是调用它而不确定 CPU 是否支持它是不正确的。

Jtimon 建议在 levelDB github 上创建一个问题。Gmaxwell 认为，最好直接提交修复，因为创建问题并不能提供太多帮助。

Cfields 后来加入了会议，他准备了一个 修复。

结论

• 修复 levelDB

高优先级审查

• Sipa 希望添加 #10148（使用非原子刷新进行块重放），这将使有效的可用 dbcache 翻倍。
• Luke-jr 已经重新整理了 multiwallet。
• Gmaxwell 提醒大家，BlueMatt 在 #10192 上的缓存更改使块连接速度提高了 31%，需要进行审查。

幽默

9:45   cfields_         here!
9:47   BlueMatt         oh, i was supposed to mention cfields_ would be late
9:47   cfields_         heh, thanks
9:47   BlueMatt         you're welcome :)

9:48   gmaxwell         we should submit a fix, it should be trivial.
9:48   cfields_         that's done already: https://github.com/theuni/bitcoin/commit/2cb7dda13884e44105f33c16e7e2c1a9aed46295
9:48   sipa             cfields_: oh!
9:48   cfields_         or are you guys talking about something else?
9:48   sipa             probably not
9:49   wumpus           lol <long discussion> oh, cfields did it already

参与者

免责声明

本摘要是在没有讨论参与者任何输入的情况下编写的，因此任何错误都是摘要作者的责任，而不是讨论参与者的责任。