

The older version inadvertently did not enable the SHA instruction set if the CPU did not support the AVX-512 instruction set.

While refactoring and optimizing, I had opportunities to review the code. For instance, the speed of the Copy command was improved by 1.49 times through multi-threading. While developing v22.5, we spent most of our time optimizing our code to improve the speed of many commands using various techniques, including multi-threading.

As a result, the time to finish the task becomes shorter. The overall CPU usages goes down suddenly at the end of the task. The new version (v22.5) dynamically manages the thread load balancing so that every thread works efficiently until the task ends. The overall CPU usage goes down suddenly at the end of the task after optimization. The following screenshots show the CPU usage before and after optimization while searching a very large file for a regular expression. To overcome this situation, I optimized the code so that v22.5 will dynamically manage thread load balancing. Nevertheless, the existence of P-Cores and E-Cores could exacerbate the situation. Just for clarification, thread speed could fluctuate even without E-Cores and P-Cores for instance, if a thread is interrupted by a background app or system process, the thread will become slower than other threads. If a P-Core thread runs faster than an E-Core thread, P-Core threads finish their task earlier than E-Core threads and need to wait for E-Core threads to finish their task. All previous versions of EmEditor assumed that all threads run at the same speed. This new architecture is interesting because a P-Core runs faster than an E-Core. Since the 12th Gen Core processors, Intel has introduced a hybrid architecture that combines P-Cores for performance and E-Cores for efficiency. I recently bought a PC with a 13th Gen Intel Core i7-13700.
