On the other hand, according to this[0] author who ported a game from assembly to C and Forth, Forth seems to drastically increase development time and perform 10-20 times worse than the equivalent assembly.
I wonder how taliforth compares to something like VFX forth or SwiftForth. I just remember running an old gforth program in swiftforth and getting something like a 15x speed increase.
Does that include using gforth-fast, which (if I understand correctly) enables JIT compilation?
I have been out of the loop for a long time, but AFAIK gforth-fast is still quite far behind the commercial forths when it comes to speed. I believe there is still room for improvement of forth speed, but iirc the VFX forth people didn't think it was worth the extra compilation time. Back then it compiled a 1MLOC project in 29 seconds, and the resulting code was plenty fast. As a baseline, a fast non-optimizing compiler should be able to compile about 1mloc a second for a moderately simple language.
In defence of Forth, the performance numbers tell us more about the Forth implementation than about Forth's performance potential, and the development time depends on whether the developer is already a competent Forth programmer.
Fundamental problem speed wise appears to mostly be an issue with the limited 65C02 arch. Quote from article "The X register has to be adjusted to make room on the data stack each time a function is called. It takes 7 cycles to save the X register to the hardware stack at the beginning of the function and restore it at the end. It takes 2 more cycles for DEX for each byte of local variable used to adjust the data stack pointer."
I think the point of article is that forth isn't exponentially slower than C.