> On Dec 23, 2019, at 8:36 AM, Lassi Kortela <[email protected]> wrote: > > There's a persistent myth among programmers that interpreters are slow.
I disagree that this is a myth. Interpreted code is typically anywhere from 5x to 100x slower than compiled code depending on the features of the interpreter and quality of the compiled code. The real issue is that developers are notoriously bad at predicting where performance matters in their code and in particular the impact of the interpreter's “slowness” on the overall performance of the application. If the interpreted code is mainly ordering the execution of rather long-running operations that are well implemented in C then the slowness of the interpreter will not be observable by the user (for example typical shell scripts executed by an interpreter-based shell). But the performance of code execution by the embedded language matters for some applications and usually the developper only knows this late in the development process (after the application’s goals have evolved) which is after the embedded language implementation has been selected and much code written around it. In such a situation it is usually too expensive to change the embedded language implementation, so instead more and more functionality gets implemented in the low-level language. So code execution performance should not be overlooked when selecting an embedded language implementation, otherwise the development benefits of the high-level language may eventually be lost. Marc
