因此，我正在使用std :: chrono库对类项目的AES和3DES密码以及CBC和OFB操作模式的实现进行基准测试。基本设置是：
chrono::steady_clock::time_point t0 = chrono::steady_clock::now();
MODECALL_E (ptext, key);
chrono::steady_clock::time_point t1 = chrono::steady_clock::now();
MODECALL_D (ptext, key);
chrono::steady_clock::time_point t2 = chrono::steady_clock::now();
其中MODECALL_E / D是宏，在编译时我将其更改为要基准测试的任何函数（特别是操作模式函数，该模式将密码函数作为模板参数，然后在内部调用它）。然后，我循环这段代码并记录由chrono :: microseconds：
进行强制转换进行加密和解密的时间。timing_return ret;
ret.etime = chrono::duration_cast<chrono::microseconds> (t1 - t0);
ret.dtime = chrono::duration_cast<chrono::microseconds> (t2 - t1);
然后将etime.count（）和dtime.count（）存储在输出文件中。
但是，在两种工作模式下，相当多的AES密码运行记录都是零时间流逝的，有时用于加密，有时用于解密。我还尝试强制转换为十亿分之一秒，以确保这不仅是分辨率问题，而且仍然有很多零输入项，因此很明显，某些功能无法正常运行。仅供参考，用于加密4 KB文本文件的典型时间（因密钥大小而异）在10-15毫秒之间。
我在GDB中运行了代码，并在调用的函数中放置了一个忽略的断点，以计算命中次数，然后...所有零条目都消失了（并且函数被命中了正确的次数）。这显然是断点的结果，因为我最初只是在加密函数中设置了一个断点，并且仍然有零个要解密的条目，然后在我向解密函数添加一个断点时消失了。不幸的是，GDB还增加了运行时间的开销，所以我不能只在其中运行基准测试。
我真的为此感到难过，有人知道发生了什么吗？我使用-O3编译了代码；可能是某种优化以某种方式跳过了函数的运行？请注意，这仅在AES密码而不是3DES上发生，而在CBC和OFB模式下都发生。
如果您还有其他需要查看的内容，可以在https://github.com/georgehodgkins/ECE5397project上找到该实现的完整代码（相当广泛），包括基准测试代码。