Share this:

Like this:

Related

4 Responses

I tend to agree, Perl’s ast based internal structure is very fast. The overhead of JIT would almost certainly be a big down side as most perl programs seem to run for a very short time. JIT makes more sense in a language designed from the ground up to be multi-threaded and memory safe so applications run for a long time in a server type role.

I think the future of Per is much more wedded to tooling – debuggers, IDEs etc. The internals of the language are pretty mature and it is hard to see much benefit with change of change’s sake.

I totally disagree. Lots of people write persistent long running web applications in Perl (using mod_perl, FastCGI or these days something like Starman) and having an optional JIT that would optimize it as it ran for days or weeks would be an amazing feature to have.

I agree it would be nice if Perl got a JIT, as I said in my second line. However, I don’t think it *needs* it.

If VM speed was that important for scripting languages, everybody would use Lua (and LuaJIT) rather than the P-languages. PyPy would have killed off CPython, etc.

And again, right, it would be nice if your Starman app ran faster for free. But really, how much difference would it make for 99% of Starman apps. Would it make sense to devote finite development resource to a JIT rather a different, more useful Perl enhancement?