c++ - 为什么 THREAD_MODE_BACKGROUND_BEGIN 导致我的代码运行速度比 THREAD_PRIORITY_LOWEST 慢 20 倍？

Question

所以我不会让您厌烦为什么，但是我的应用程序可以选择使用 CRC 对非常大的文件(最多 50gb)执行一些完整性检查。因为我不想在用户打开此选项时杀死他们的机器，所以我在句柄上设置了 IoPriorityHintVeryLow 提示，并且还使用 this API 将线程优先级设置为 THREAD_MODE_BACKGROUND_BEGIN。 .

我的代码中耗时的部分如下所示:

//
// Read one block of the changed data at a time, checking each CRC
//
DWORD blockNum = 0;
vector<BYTE> changeBuffer(DIRTY_BLOCK_SIZE);
outputDirtyBlockMap.reserve(crcList.size() / 8);
while (::ReadFile(hChangedFile, changeBuffer.data(), DIRTY_BLOCK_SIZE, &bytesRead, NULL) && bytesRead > 0)
{
    // Check for cancellation every 500 blocks, doing it every time reduces CPU performance by 50% since WaitForSingleObject is quite expensive
    if ((blockNum % 500 == 0) && IsCancelEventSignalled(hCancel))
    {
        RETURN_TRACED(ERROR_CANCELLED);
    }

    // Increase the size of the dirty block map?
    ULONG mapByte = blockNum / 8;
    if (mapByte == outputDirtyBlockMap.size())
    {
        outputDirtyBlockMap.resize(mapByte + 1);
    }

    DWORD mapBitNum = blockNum & 0x7L;
    UCHAR mapBit = 1 << (7 - mapBitNum);
    if (driverDirtyBlockMap.size() > mapByte && (driverDirtyBlockMap[mapByte] & mapBit))
    {
        //
        // The bit is already set in the drivers block map, we don't have to bother generating comparing CRCs for this block
        //
        outputDirtyBlockMap[mapByte] |= mapBit;
    }
    else
    {
        // Validate that the CRC hasn't changed, if it has, mark it as such in the dirty block map
        DWORD newCrc = CRC::Crc32(changeBuffer.data(), changeBuffer.size());
        if ((blockNum >= crcList.size() || newCrc != crcList[blockNum]))
        {
            OPTIONAL_DEBUG(DEBUG_DIRTY_BLOCK_MAP & DEBUG_VERBOSE, "Detected change at block [%u], CRC [new 0x%x != old 0x%x]", blockNum, newCrc, blockNum < crcList.size() ? crcList[blockNum] : 0x0);

            // The CRC is changed or the file has grown, mark it as such in the dirty block map
            outputDirtyBlockMap[mapByte] |= mapBit;
        }
    }

    ++blockNum;
}

当我分析这段代码时，我非常惊讶地发现当这个循环在 THREAD_MODE_BACKGROUND_BEGIN 中运行时，运行一个 500Mb 的文件需要 74 秒。使用 THREAD_PRIORITY_LOWEST 运行时，运行 500Mb 文件需要 2.7 秒。 (我已经测试了大约 8 次，这是平均值)

在这两种情况下，我测试的机器除了运行这个循环外都是空闲的。所以问题:

为什么 THREAD_MODE_BACKGROUND_BEGIN 会花费这么长时间？我本以为如果机器没有做任何其他事情，它仍然应该像任何其他优先级一样快速运行，因为它不需要优先级？

关于这个优先级，有什么我应该知道但我无法从文档中弄清楚的吗？

Answer 1

设置背景模式有以下效果:

• 将 I/O 优先级设置为非常低
• 将内存优先级设置为 1
• 将绝对线程优先级设置为 4

将相对线程优先级设置为 LOWEST 具有以下效果:

• 将相对线程优先级设置为 -2(即:绝对 6，假定正常进程优先级等级)

因此，一般来说，特别是如果您受 I/O 限制(但即使在受 CPU 限制的情况下)，您肯定会期望优先级为 4 的线程以非常低的 I/O 优先级和后台内存优先级运行(1) 比前台内存优先级 (5) + 普通 I/O 优先级为 6 的线程执行得更差...