I almost added that a good optimizer would eliminate the 0=='\\\\' test, but decided that is irrelevant to this thread. However, out of curiosity about the MSVC v19 code generator given optimization flags, I looked at assembler output for both the bc3bf7c6 check-in and the proposed replacement. Here are the results, lightly annotated in comments: ``` ; Original code: ; Line 123565 lea r10d, DWORD PTR [rbx-1] mov QWORD PTR [rax], rcx mov ecx, ebx sub rcx, 1 js SHORT $LN205@sqlite3Loa $LL7@sqlite3Loa: cmp BYTE PTR [rcx+rsi], 47 ; '/' je SHORT $LN205@sqlite3Loa dec r10d sub rcx, 1 jns SHORT $LL7@sqlite3Loa $LN205@sqlite3Loa: ; Revised code: ; Line 123567 lea r10d, DWORD PTR [rbx-1] mov QWORD PTR [rax], rcx mov ecx, ebx sub rcx, 1 js SHORT $LN203@sqlite3Loa npad 7 $LL7@sqlite3Loa: movzx eax, BYTE PTR [rcx+rsi] cmp al, 47 ; '/' je SHORT $LN203@sqlite3Loa cmp al, 92 ; '\\' je SHORT $LN203@sqlite3Loa dec r10d sub rcx, 1 jns SHORT $LL7@sqlite3Loa $LN203@sqlite3Loa: ``` As can be seen in the 'cmp al, ?' instructions, the 2nd test is optimized out when it could not succeed. The optimizer recognized this, not via constant expression analysis but by analyzing the possible values of c when the 2nd test was reached. As can also be seen, the possibly performant conversion of code that might be written: ``` zFile[iFile]!='/'&&zFile[iFile]!='\\' ``` into something that avoids an indexing operation: ``` (c=zFile[iFile])!='/'&&c!='\\' ``` is not needed with this particular optimizing compiler. I dare say that recognizing common subexpressions such as 'zFile[iFile]' is an easier and more common optimizer feature than the one demonstrated in the above assembler output. Of course, this code runs after a DLL has been loaded, after some file reads and many thousands of instructions run to (dynamically) link it, so the possible elimination of a load instruction is like a sneeze in a hurricane.