这不是最近的回归,也许正因为这个原因它不会被修复,但我想我还是会提交这个问题。
我维护这个库的Go绑定,幸运的是我在开始时就有了基准测试。在某个时刻,我注意到解码过程中有一个regression,但直到现在才开始调查它。长话短说,我已经在这个仓库中进行了二分查找并找到了根本原因。以下是用于找到它的基准测试。
回归详情:
decode time: [3.9277 µs 3.9409 µs 3.9558 µs]
change: [+241.37% +242.64% +244.06%] (p = 0.00 < 0.05)
Performance has regressed.
虽然解码速度很快(微秒级别),但+240%的减速幅度相当大,我想知道我们是否能恢复这种性能。
基准测试代码( tokenizers/benches/decode_benchmark.rs
):
use criterion::{black_box, criterion_group, criterion_main, Criterion};
use tokenizers::tokenizer::Tokenizer;
fn decode(tokenizer:&Tokenizer, ids_slice: Vec<u32>, skip_special_tokens: bool) -> String {
tokenizer.decode(ids_slice, skip_special_tokens).expect("failed to decode input")
}
fn criterion_benchmark(c: &mut Criterion) {
let tokenizer = Tokenizer::from_file("./test/data/bert-base-uncased.json").expect("failed to create tokenizer");
c.bench_function("decode",
|b| b.iter(
|| decode(&tokenizer, black_box([2829, 4419, 14523, 2058, 1996, 13971, 3899].to_vec()), black_box(true))));
}
criterion_group!(benches, criterion_benchmark);
criterion_main!(benches);
将此添加到Cargo.toml
并使用cargo bench decode
运行。
[[bench]]
name = "decode_benchmark"
harness = false
令牌化文件从here复制而来。
8条答案
按热度按时间yqhsw0fo1#
是的,我认为我在挑选它,在运行之前/之后我会检查一下。
llmtgqce2#
哇,非常感谢清晰的报告!
是的,240%并不好!好的,我会调查,但在此期间,如果您有一个修复问题的PR,那就太好了!
iyfamqjs3#
I'll add this to benches! 🆙
rqenqsqc4#
我查看了你提到的提交,不得不创建一个自定义分支来测试:
test-old-decode
。我从fast-decode-fix
中挑选了我添加的测试,它只有基准测试,我会在这里发布结果!2q5ifsrm5#
目前看来,
似乎已经解决了这个问题。
1cosmwyk6#
目前看来问题已经解决。
你的意思是你在头部看不到回归吗?我只是同步以确认性能下降。不要看变化百分比,因为这似乎报告自上次基准测试运行以来的更改,只需比较绝对值,例如我在头部连续运行两次得到的结果:
u2nhd7ah7#
我会再检查一次!我得到的两个分支都是630ns,但我要确保这一点!
5uzkadbs8#
哦,我刚刚检查了
test-old-code
和 branch,它们包含了引入回归的提交( #938 )。您想要比那个提交早一个分支 :)