I'm writing an interpreted implementation of a new programming language (just for fun). In this implementation language is first being compiled to an intermediate language, which is then interpreted by an interpreter. Interpreter is written in Mono C#. However I got this idea to translate methods, which return no data to C++ code and then compile this code and launch it at runtime. That way some methods could run faster. Would that be considered as a bad practice/idea?
Would that be considered as a bad practice/idea?
Enh? My first instinct is that you wouldn't gain much in performance. Spinning up a new process and sending in the data is a bit heavyweight.
My second instinct is I'm not sure how general you're going to be able to do it. Just because methods return no data doesn't mean they don't work with data. You're still going to need to be able to turn the interpreter data into some format the C++ code can get at. And since most languages allow side effects, the C++ code will need to be able to make changes and send the data back. No, "then I'll detect if the code has side effects" isn't a viable solution since that's a generally unsolvable problem for languages of any complexity.
If you're going to target a compiled language, you're probably just better off making a compiler to target that language rather than half-interpreting things.
This is what JITters do. It's a good idea, but it won't help performance unless you do it for innermost code - i.e. the code where the program counter is most often found. There's little to be gained by optimizing code that is relatively seldom executed.
It the program spends most of its time waiting for I/O, then optimizing it will also not help, not unless you can eliminate the I/O.
By the way, if you forget writing the interpreter and directly generate C++, that also is a perfectly good way to go. You get both the performance of C++, and access to all of the library functions available for it.