According to this article: german C64 Wiki article about the POS() command POS(π) is 20 % faster.
Although in my experience it is circa 28 % faster. Is there a specific reason for this immense speed boost?
That interpreter apparently parses the source text, or at least the numerical literal values, at every execution. π is a single-byte magic token, therefore, as soon as it is recognized, it is immediately substituted with the value of Pi, and nothing else needs to be done.
When a byte that might occur in a number is parsed, the number parsing routine begins. Its execution time will depend on the number of characters in the string representing the number. When parsing a number, each digit in the integer part requires multiplying the number parsed so far by 10 and adding the value of the digit. The fractional part is usually parsed as an integer, then divided by the appropriate power of 10. The division operation is expensive, and it makes sense to check if the dividend is 0 before dividing — that's why
.0 is much faster than
That's why, as the German Wiki article says, the next best execution time is for
POS(.): the number parsing routine starts, but there are no digits to parse, and it devolves to skipping the period and adding the initial (zero) values of the integer and the fractional part, then for a variable with a single-character name (name lookup), and then for the number 0 (will cause the computation of 0 * 10 + 0). Longer numbers will take even longer.
The C64 BASIC uses a floating point as basic format for everything. So even if a function requires an integer argument, the number is parsed into a floating point number first and then converted into an integer. When giving the constant π, a pre-stored floating point value of 3.14159265 is used, so the time for the conversion of the number to floating point is omitted. For POS(), the argument is a dummy argument, so its value does not matter to the result, which makes POS(π) easily possible. But even for other functions like POKE giving π as an argument (which will then be converted to 3) would be a bit faster than writing a 3.