From 676d19793a7bd65af7037af82d4291f4c5509d1f Mon Sep 17 00:00:00 2001 From: Andrew Leech Date: Thu, 20 Jun 2024 11:16:22 +1000 Subject: [PATCH] Updated Improving performance with Viper code (markdown) --- Improving-performance-with-Viper-code.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Improving-performance-with-Viper-code.md b/Improving-performance-with-Viper-code.md index 9809a36..2aaf002 100644 --- a/Improving-performance-with-Viper-code.md +++ b/Improving-performance-with-Viper-code.md @@ -70,7 +70,7 @@ These data types are very fast. They are not implemented as an MicroPython objec Most of the difficulties using the Viper code emitter are related to the use of these data types and their peculiarities. So here goes a lot of detail about these data types. -Viper variables are "raw" variables and are not stored as MicroPython objects. In contrast the string, tuple, list and integer variables we all know are always stored ad MicroPython objects. +Viper variables are "raw" variables and are not stored as MicroPython objects. In contrast the string, tuple, list and integer variables we all know are always stored as MicroPython objects. The Viper code emitter detects Viper variables at compile time, and generates very fast code for the operations. For example ```x = 0``` or ```x = int(myfunction())``` will make `x` Viper `int` variable. Now, `x = x + 1` will be compiled around 2 or 3 machine code instructions!