我在给 try parseLine(line) 和 parseLine(line) catch unreachable 计时,输入是大约 200 万条生成的 ts,level,bytes 行,对 bytes 求和。用 -Doptimize=ReleaseFast 构建。
try 那一版报出几百微秒,打印的是一个错误名,而不是总和。catch unreachable 那一版要跑几十毫秒,总和也不一样。ReleaseSafe 和 Debug 下第二个会 panic。我每 5000 行加了一条坏行,想让它“更真实”。用 --bad-every 0 的话看起来正常些,但我不明白为什么影响这么大。
两个循环如下。
const e = try parse.parseLine(line);
total += e.bytes;
// vs
const e = parse.parseLine(line) catch unreachable;
total += e.bytes;
我猜是错误返回跟踪或者内联,汇编还没看。输入生成已经在计时器之外了。(splitScalar 好像是 0.12 左右出现的,我记得是这样,不对就算了。)
所以这到底在测什么?谢谢大家指点。
从英语翻译·查看原文I'm timing try parseLine(line) against parseLine(line) catch unreachable over ~2M generated ts,level,bytes lines, summing the bytes. Built with -Doptimize=ReleaseFast.
The try run reports a few hundred microseconds and prints an error name instead of a total. The catch unreachable run takes tens of ms, and its total is different. ReleaseSafe and Debug panic on the second one. I added a corrupt line every 5000 lines to "make it realistic". With --bad-every 0 things look saner, but I don't get why it matters this much.
The two loops:
const e = try parse.parseLine(line);
total += e.bytes;
// vs
const e = parse.parseLine(line) catch unreachable;
total += e.bytes;
My guesses were error return traces or inlining. I haven't looked at the assembly yet. Input generation is already outside the timer. (splitScalar showed up around 0.12, I think, nvm if that's off.)
So what is this actually measuring? Thanks for any pointers.