Dank dieser Optimierungen ist sie bis zu drei mal schneller als typische atoi() Implementierungen aus diversen Bibliotheken. Dabei wird nur ein trivialer Akkumulatoralgorithmus verwendet. Durch mehr Code, mehr Speicher und weiteres Ausreizen von CPU Details kann noch einiges an Performance herausgeholt werden. Beispielsweise könnte man auf einem Pentium statt byte-Arithmetik die '0' mittels int-Arithmetik von vier bytes gleichzeitig subtrahieren.

Hier wurde ganz besonders auf Parallelläufigkeit der U- und V-Pipeline des Pentium geachtet:

; MASM-Syntax ; sc/11.07.94 TITLE atoi_L .386 .MODEL small PUBLIC _atoi_L .CODE ; 32-Bit-Segment _atoi_L PROC ;Takte push ebx ; 1 push esi ; 1 mov esi, [esp+12] ; 2, 4+2*4=12 xor eax, eax ; 2 push edx ; 3, wegen [esi]-BI push ecx ; 3, wegen [esi]-BI mov dl, [esi] ; 4 xor ebx, ebx ; 4 cmp dl, '0' ; 5 jae SHORT $digit ; 5 inc esi $digit: push edi ; 6 xor edi, edi ; 6 mov ecx, 10 ; 7 $loop: mov al, [esi] ; 1/7 add edi, edi ; 1, edi(=ebx) *= 2 sub al, '0' ; 2 js SHORT $break ; 2 cmp al, 9 ; 3 ja SHORT $break ; 3 lea ebx, [edi+ebx*8] ; 4, ebx *= 10 inc esi ; 4 add ebx, eax ; 5 dec ecx ; 5 mov edi, ebx ; 6 jg SHORT $loop ; 6 $break: cmp dl, '-' ; 1 jne SHORT $pos ; 1 neg ebx $pos: mov eax, ebx ; 2 pop edi ; 2 pop ecx ; 3 pop edx ; 3 pop esi ; 4 pop ebx ; 4 ret ; 6 ALIGN 4 _atoi_L ENDP END

--HelmutSchellong

Allein durch diese Optimierung kann ein Programm insgesamt sehr viel schneller werden, falls diese Funktion oft aufgerufen wird.

Zum Beispiel Auswertungsprogramme für Logdateien. Da textuelle Logs wesentlich flexibler in der Handhabung sind, ist das für viele Programme der primäre Outputkanal. Diese Logdateien wieder aufbereiten würde von einer effizienteren atoi() Funktionalität sicher profitieren. Auch da die vorliegenden Dateien meistens einem strengeren Format genügen, als atoi() erlaubt. Siehe auch OptimierenJaOderNein.

Insbesondere Script-Interpreter, die einen Arithmetik-Modul haben.