A modern programming language that makes developers happier.

kotlinlang

Hey. I have a use case for Kotlin Script where I need to compile Kotlin scripts in runtime in batches (size various from 1 to let say 100). Locally everything is working quite well, but we face some IO bottlenecks when app is deployed to cloud. I was tasked to analyze if we can improve how we compile the Kotlin scripts so it will take less resources.

After some investigation I found that default compiler is using `ScriptJvmCompilerIsolated` which is creating `KotlinCoreEnvironment` for each compilation and it takes considerable amount of time. As a alternative I asked the `BasicJvmScriptingHost` to use the `ScriptJvmCompilerFromEnvironment` (based on default configuration of `ScriptJvmCompilerIsolated`). I faced some issues with memory consumption of this solution and I am wondering if this is a proper way to improve performance?

Hi <@U0C1AKVC6>!
This is somewhat complicated, and in general - no, this is not the right way to improve performance, at least not now.
Sharing of the compiler internals is generally unsupported for a moment. In the some bright future we will definitely support it better, but no promises or dates for now.
From the available mechanisms to speed up things, you can try to avoid compilation of the same scripts using caching.

Hi <@U0CHHN4F4>. I work with <@U0C1AKVC6>. Thanks for your  reply. Just to confirm: You are saying that it is currently not possible to load static resources (such as the classpath from an unpacked fat-jar)  once and reuse it across multiple compilations?

Hi <@UMR0J3431>. I'm not sure I understood your question correctly.
The compilation infrastructure consists of many parts, including the internal structures and classes used during compilation, the dependencise (JDK and external libraries) that should be loaded (via our own deserialization mechanisms) and presented for the compiler for symbol lookup, the intermediate representations generated during compilation, etc. All this was designed and optimized mainly for the one-shot scenario, and in particular most of this is not designed to be reused between compilations. The scripting/REPL gave us the new usage scenarios, where the sharing is important, so we're looking into improving internals for them, but it's a long road ahead.
There is the partially similar functionality that works inside IDEs, where sharing is implemented, but these parts are not suitable for scripting yet for other set of reasons.

<@U0CHHN4F4> Thanks. You answer was relevant to the intention of my question. Are there any issues we can follow to monitor this? Or maybe even contribute?

Unfortunately there is no a root issue to follow or even a list of relevant ones, the topic is somewhat vague yet. But I hope that we will sort it out some day to make a clear and trackable plan.