Startup Time Improvement

[hj-lee]

Hi,

I made a change to reduce the statup time of kscript:

• Call the main method of the script using classloader instead of excuting kotlin again (No double java startup time) (Scripts using KOTLIN_OPTS are exceptions)

In addition to KOTLIN_OPTS, users can specify -J Java options to kscript directly. (ex - kscript -J-Xmx8G memory-hungry-script.kts). If both of KOTLIN_OPTS and -J options are supplied, only KOTLIN_OPTS will be used to run the script.

(edit1 - KOTLIN_OPTS support)
(edit2 - remove the mention of fat-jar)

[holgerbrandl]

Thanks for your ideas. Getting rid KOTLIN_OPTS is not going to work. First because of backwards compatibility, and second because the shebang line in interpreter usage does not allow for multiple arguments on all platforms.

[holgerbrandl]

My idea to improve startup time, is to compile kscript with kotlin-native once the latter is mature enough to support all required APIs (file-io, networking, logging).

[hj-lee]

Hi, I made the patch support KOTLIN_OPTS. If a script contains KOTLIN_OPTS, kscript will launch a new kotlin(java) process.

[holgerbrandl]

Thanks, I'll need some time work work through this very exciting PR.

[hj-lee]

Hi, I think fat jar commit can be proplematic if the kscript build kotlin version and installed kotlin version are differnt. I can make the branch only has the first two commit (or a squashed commit) or I think you can choose which commits you want to pull. (Can't you? I'm new to githup pull request.)
-- edit: c.f. the next comment.

[hj-lee]

Also, the compiler call commit is not necessary. It may reduce startup time of not-yet compiled script and startup time of the interactive mode, but it is too closely coupled the implementation of kotlinc. It is needed to support interactive mode, but with KOTLIN_OPTS commit, we have a way to run interactive mode without it.

Ah, I realized I forgot the interactive mode when I made "Support KOTLIN_OPTS again" commit.

[hj-lee]

Hi, I found out calling the script main does not work sometimes. (https://github.com/JetBrains/Exposed example does not work in the previous commit.) I experimented calling runner Main, and it works well. Unfortunately, as fat jar does not work well with the runner Main change, I gave up the fat jar change.

[holgerbrandl]

To push this exciting PR forward I did some benchmarking today

You can find the benchmarking code in the repo under https://github.com/holgerbrandl/kscript/tree/master/misc/benchmarking

So it seems there is a decent speed improvement if the script jar is cached. :-)

[holgerbrandl]

Why do we need the follow-up file (which looks a bit hacky to me)? Couldn't we simply print the follow-up command similar to how it is done until now?

Secondly, I agree to the argument in #84 , kscript should allow to set compiler settings. Do you think this could be supported as well?

Why did you push the --interactive handling to happen after the compile step? Doing earlier seems with me.

More as a reminder to me. We still need to benchmark examples with KOTLIN_OPTS and add unit-tests for these cases.

I could not follow your argument in your last comment about " script main does not work sometimes. ". Could you detail it out a bit further?

[hj-lee]

The benchmark result looks nice (if the script jar is cached :-) )

Why do we need the follow-up file (which looks a bit hacky to me)? Couldn't we simply print the follow-up command similar to how it is done until now?

The basic idea is using the same Java runtime - used to prepare script jar - to run the script main. That means Kscript.kt main function should not print out its own output while preparing the script jar. Instead, the running script owns the output of the Java runtime (the first kotlin command).
The follow-up file is used only when the script has KOTLIN_OPTS. In that case, it is necessary to execute the second kotlin command (as the current Java runtime is already running). As the first kotlin command output is used by the script, I used follow-up file as a way to tell the 'kscript' bash script to run the content of the follow-up file.

Secondly, I agree to the argument in #84 , kscript should allow to set compiler settings. Do you think this could be supported as well?

Yes, as Kotlinc.compile calls compiler main method with command line arguments, supporting additional compiler options will be straightforward. If Java options are given as compiler options, we can use evalBash function. (It would be much simpler than follow-up file method used in Kscript.main) Actually, I hoped that calling compiler main would decrease compile time, but the benchmark results seem to be the opposite of my expectation. :(

Why did you push the --interactive handling to happen after the compile step? Doing earlier seems with me.

I thought it would be better if we can use functions defined in the script file and included .kt files in the interactive shell (although it works only for .kt scripts.) Now, I think it is appropriate as a separate pull-request or a commit, not incorporated like this. Your call. If you don't like the idea, I will change the commit. :)

More as a reminder to me. We still need to benchmark examples with KOTLIN_OPTS and add unit-tests for these cases.

As specified before, if the script has KOTLIN_OPTS, there would be no performance gain. Regarding tests, I used Runtime.getRuntime().maxMemory() to check if -J-Xmx option works correctly or not.

I could not follow your argument in your last comment about " script main does not work sometimes. ". Could you detail it out a bit further?

Sorry for causing the confusion. If you haven't looked at the previous commits, it would be confusing. For the record, I changed the branch a few times, and the last change was made about the time I left the comment. At first, I think calling the script(execClassName) main would work, and it worked. But, later, I found some cases which it fails to run. So, I mimicked the way 'kotlin' script works - which calls org.jetbrains.kotlin.runner.Main to run .kt main -, and the problem was solved. I guess kotlin does some preprocessing before running the real main method.

[hj-lee]

I thought of a way to support KOTLIN_OPTS without followup-files:
It is using ProcessBuilder with inheritIO(). Although the new approach has a drawback - that there will be two java processes -, I think this approach is better than the followup-files approach. It is less hacky and it will solve issue #98 regardless of KOTLIN_OPTS presence.

I'm experimenting with the idea, and it seems to be working well on Linux. I haven't tested it on Windows(cygwin) yet. If it works well on Windows too, I can make a separate pull-request to compare the two implementations.

[holgerbrandl]

Hi @hj-lee . I cleared most other remaining tickets today, which unfortunately created some merge conflicts in your PR. Sorry for that.

I really like the idea of using inheritIO instead of the followup-file. This will keep bash (which is not really consistent across platforms) on a minimum, and also gives a clearer flow imho.

Also indeed the PR seems a nice fix for #98.

I'd love to help to work on the PR. So maybe we could move it into a separate branch within kscript repo, so that we could both help to evolve it?

[hj-lee]

Hi @holgerbrandl, I'm working for the new implementation on the new master. Actually, I have a working code which passes the test_suite and new --package is working, but it's a little bit messy now. I guess I can make a new PR request in a few days.