我最近购买了一台配备第 13 代英特尔酷睿 i7-13700 的电脑。自第 12 代酷睿处理器推出以来,英特尔推出了混合架构,将P 核与E 核相结合以提高性能和效率。这种新架构很有趣,因为 P 核的运行速度比 E 核更快。EmEditor 的所有早期版本都假定所有线程以相同的速度运行。如果 P-Core 线程的运行速度比 E-Core 线程快,则P-Core 线程比 E-Core 线程更早完成任务,并且需要等待 E-Core 线程完成任务。需要澄清的是,即使没有 E 核和 P 核,线程速度也可能会波动;例如,如果一个线程被后台应用程序或系统进程中断,则该线程将变得比其他线程慢。然而,P 核心和 E 核心的存在可能会加剧这种情况。
为了克服这种情况,我优化了代码,使v22.5 能够动态管理线程负载平衡。以下屏幕截图显示了在非常大的文件中搜索正则表达式时优化前后的 CPU 使用情况。优化后任务结束时整体CPU使用率突然下降。
以前的版本 (v22.4.2) 假设每个线程以相同的速度运行。因此,某些线程比其他线程更早完成,并且总体 CPU 使用率在搜索任务结束时逐渐下降。
新版本(v22.5)动态管理线程负载平衡,使每个线程高效工作,直到任务结束。任务结束时,总体 CPU 使用率突然下降。结果,完成任务的时间变得更短。 在开发v22.5时,我们花费了大部分时间来优化代码,以使用各种技术(包括多线程)来提高许多命令的速度。例如,通过多线程, Copy命令的速度提高了1.49倍。在重构和优化的同时,我有机会审查代码。如果CPU不支持AVX-512指令集,旧版本无意中没有启用SHA指令集。v22.5修复了此错误并提高了多个命令的速度,包括在许多不支持AVX-512的 CPU 上删除重复行。我将在未来的版本中继续审查和优化代码以提高速度。
当我第一次使用我的新 PC 用 Visual C++ 构建代码时,我很失望地发现构建速度非常慢。我们发现,在构建代码时,内存使用率达到了 100%,因为只有 16 GB 的物理内存 (RAM) 可用。CPU 有 24 个逻辑核心,Visual C++ 使用 24 个线程来构建代码。在 Visual C++ 选项中将线程数从 24 调整为 7,使编译器构建代码的速度更快。同样,与使用 3 个线程相比,使用 24 个线程时 EmEditor 速度更慢。将物理内存从 16 GB 增加到 80 GB 使两个应用程序在 24 个线程下速度更快。因此,如果您拥有具有大量逻辑核心的现代 CPU,我强烈建议增加物理内存。例如,如果您的 CPU 有 24 个逻辑核心,我建议您的 PC 至少配备 32 GB 物理内存。线程数,可以在 EmEditor 的“自定义”对话框的“高级”页面上指定。在v22.5中,如果逻辑核心数量超过此 GB 值,我会将默认线程数调整为最接近的 GB 物理内存量。
一位客户要求改进文件更改检测。旧版本默认每 5 秒检查一次当前文件大小和时间戳,如果确定文件已更改,则会显示一个消息框“文件已被另一个程序更改。” 重新加载更改?”就会出现。v22.5 使用 Windows API 更有效地检测文件更改。