format PE64 console
entry start

include 'win64a.inc'

section '.text' code readable executable

start:
        sub    rsp, 20h
        mov    rcx, string
        mov    rdx, stringlength
        mov    r8,  substring
        mov    r9,  substringlength
        call   SnR

        ; Dump first 16 bytes for a replacement quick test
        cinvoke printf, <'0x%llx | '>, string
        cinvoke printf, <'%llx', 32>, qword [string]
        cinvoke printf, <'%llx', 32, '|', 32>, qword [string+8]
        xor    r15, r15
        @PLoop:
        cinvoke printf, <'%c'>, qword [string+r15]
        add    r15, 1
        cmp    r15, 15
        jb     @PLoop

        cinvoke getch
        invoke  ExitProcess,0

SnR:
        ; Search (case insensitive) and replace all substrings in a string
        ; for the sake of speed, the procedure is intentionally limited at some points
        ;
        ; rcx = pointer to string
        ; rdx = length of string (bytes)  can be in range 16~384
        ; r8  = pointer to substring
        ; r9  = length of substring (always = 16 bytes here)
        ;
        sub     r9,  2h               ; 

        ; cmp    rdx, r9              ; ommited - the size is known and string always > substring
        ; cmp    rdx, 0               ; ommited - the size is known and always > 0

        xor r10, r10 ; buff ^
        xor r11, r11 ; patt ^

        ; Enter the compare loop
    @Loop:
        movzx eax, word [rcx + r10] ; eax Instead of ax for breaking dependences
        movzx ebx, word [r8  + r11] ; ebx Instead of bx for breaking dependences

        cmp eax, ebx                ; not [xor ax, bx + jz] since it will change 'ax' and the next check (if present) will be invalid
        je  @Match
        xor eax, $20                ; | 
        xor eax, ebx                ; | Uncomment for case insensitive search (works for us since substring contains letters only [A-Z]|[a-z])
        jz  @Match                  ; |
      
    @Mismatch:
        xor r11, r11                ; reset the position in the substring (look for the first character again)
        lea r10, [r10+2h]           ; shift to the next string character  (same as add r10, 2h)
        cmp r10, rdx                ; check if we have reached the end of the string
        jb  @Loop                   ; keep searching
        jmp @NotFound               ; end of the string
      
    @Match:
        lea r10, [r10+2h]           ; shift to the next string character    (same as add r10, 2h)
        lea r11, [r11+2h]           ; shift to the next substring character (same as add r11, 2h)
        cmp r11, r9                 ; check if we have reached the end of the substring
        jae @Found
        cmp r10, rdx                ; check if we have reached the end of the string
        jb  @Loop                   ; keep searching

    @NotFound:
        xor rax, rax
        ret
      
    @Found:
        ; for each match, replace the substring 
        lea rsi, [replacement]      ; src
        lea rdi, [rcx]              ; dst
        add rdi, r10                ; Calculate the absolute address of the current search position in the string
        sub rdi, r9                 ; Shift to the beginning of the match
        movsq                       ; replace the found instance
        movsq                       ; twice to replace all 16 bytes
        jmp @Mismatch               ; keep searching



section '.data' data readable  writeable
    ; the string
    string:       du 'Substing',176 dup('x'),'Substing',0
    stringlength = $-string

    ; the substring
    substring:    du 'Substing'
    substringlength = $-substring

    ; the replacement
    replacement:  du 'REPLACED' ; always same size as substring


section '.idata' import data readable ; writeable
    library kernel32,'KERNEL32.DLL', msvcrt, 'msvcrt.dll'
    import msvcrt,   printf, 'printf', getch, '_getch'
    import kernel32, ExitProcess, 'ExitProcess'    

In general it is hard to say really.

There is more than enough background details to advise on this particular implementation.

With only a single example string and search pattern given I don't think it will help for any real application. Unless the real app only uses that single string and search pattern.

CPU type, the mobo, the RAM, the OS, other tasks running, the cache state, etc

RAM speed has an effect on code performance. But also RAM size. If other tasks are taking memory, perhaps there a lot of swapping, or TLB misses, or cache misses, etc.

CPU has an effect. An AMD E350 will give different performance results than an Intel 10900X, you will need to use different instructions to get the best performance for each.

32-bit vs 64-bit OS has an effect. Some code runs better in 64-bit, some is better in 32-bit, but the OS used can limit the choice and force one to use slower code.

Other OS tasks can have higher priorities causing starvation of runtime for other apps.

The length of the string matters for cache performance. If it is always one byte more than the cache line width then you can get bad performance. If it is some mixture of variable lengths, then the performance will change depending upon the nature of the input data.

Generally ... for any hardware ... generic ... the general direction is what really matters ...

But let's skip the general optimization tips, they are known.

        ; Search (case insensitive) and replace all substrings in a string
        ; for the sake of speed, the procedure is intentionally limited at some points
        ;
        ; rcx = pointer to string
        ; rdx = length of string (bytes)  can be in range 16~384
        ; r8  = pointer to substring
        ; r9  = length of substring (always = 16 bytes here)    

The use of Unicode strings in Windows ...

Unicode is not a string format. Something like UTF-8, or ASCII, are. You need to define an encoding before you can use Unicode.

When the structure of the code is optimized you will have one loop and one exit condition (predictable). Within the main loop will be another branch (unpredictable) around the match case.

Perhaps a LUT+skip algorithm is more optimal for the actual source data.

]The LUT+skip code would also fit the model I suggest. The match method is irrelevant.

I'm speak generally, and didn't even consider the static case presented.

But let's skip the general optimization tips, they are known.

The match method is vital, it is the heart of the task.

Now you also see the problem.

Is the function written so well that no one has been able to suggest optimization even for a single instruction in it?
Apparently I deserve a beer

We have written to you how to optimize it

use lengths in characters instead of bytes...For example: rdx = 21 (bytes) is an invalid string or a 10-character string