Процедурите ти за работа със стрингове не са много оптимални. Не, че не работят ама примерно при сравнението на стрингове като им изчислиш първо дължините вече си ги прочел за да намериш къде е им е терминиращия 0x00 т.е. като така и така ги четеш спокойно можеш да правиш и сравнение символ по символ.
Има един образ който много се заиграва с такива неща - Daniel Lemire ако не го знаеш хвърли едно око, има интересни статии за бързи алгоритми и цепене на цикли.
Грешиш. StrLen е със сложност О(1) така че в 99% от случаите няма забавяне и двойно сканиране. А ако потребителят подаде стрингове в C формат, то да, има двойно сканиране, но това по принцип е fallback случай, така че не е голям проблем.
Не бе, говоря за четенето на самите стрингове, че ще ги прочетеш двойно - един път за да видиш колко са дълги и евентуално втори път за да сравниш байт по байт дали са еднакви. Всичкото това може да се направи в един цикъл:
next:
lodsb
or al, al
je exit
scasb
je next
exit1:
mov eax, 1
ret
exit:
scasb
jne exit1
mov eax, 0
ret
И въобще, това че пиша на асемблер в общият случай съвсем не значи, че оптимизирам всичко по производителност. Точно обратното – в повечето случаи оптимизирам по размер.
Общата висока производителност на асемблерските програми се дължи на съвсем друг ефект.
Какъв е този съвсем друг ефект?