3 ms·

Fantastic for sharing, though the startup time improvement is minor (e.g. I saw 17% improvement). BTW: that SO comment references a pdf that shows how to includ

• greyboy 13y ago
  Interesting about keeping a JVM running for compilation. I'm curious about doing just this for my day job but can't seem to find a good explanation. Do you have any resources to point me to?
  • 6ren 13y ago
    javac is itself written in java, so you can write a little program that does that in a loop, waiting for some trigger. I actually just had it in a shell, waiting for you to hit return, which also called my code after compilation. An unexpected benefit (unexpected to me, anyway) was that not only do you avoid the startup penalty, but you also benefit from JIT compilation of javac itself - every time it compiles, it gets faster! IIRC it's fairly substantial the first 10 times, but still improving at 50. Here's a working minimal starting point I just put together for you (check docs, google, stackoverflow etc): import javax.tools.*; import java.io.*; class Demo { public static void main(String args[]) throws IOException { JavaCompiler compiler = ToolProvider.getSystemJavaCompiler(); int result = compiler.run(null, System.out, System.out, args); } } java Demo Foo.java # compiles Foo.java Here's a stackoverflow answer suggesting something similar http://stackoverflow.com/a/793913/50979 http://stackoverflow.com/a/793913/50979 BTW: I called out to a bash script to work out which source files had changed, because it's easier than writing that bit in java (and this compiler doesn't do that for you - it just compiles the explicitly listed source files). HTH - let me know if you need more info. I've been thinking of using Jnotify to watch for source files being written to, so it's 100% automatic - one issue is that I save quite often, and each will trigger a compile (I'm doing this with plain javac and inotify at the moment).
  • jared314 13y ago
    For a persistent JVM, take a look at Nailgun [1]. Additionally, the Drip project [2] uses a swapping strategy, by keeping an additional JVM spun up in the background. It was apparently built because the authors had trouble with persistent JVMs containing old dependencies. [1] http://www.martiansoftware.com/nailgun/ http://www.martiansoftware.com/nailgun/ [2] https://github.com/flatland/drip https://github.com/flatland/drip
• rektide 13y ago
  If one needs to be launching only a fixed set of programs fast, perhaps give CRIU, checkpoint restore in userspace, a try? Give the program time to warm up and load, checkpoint it, then restore a copy: run an already copy, rather than repeat the startup afresh. Post on CRIU from the same day: https://plus.google.com/113218107235105855584/posts/CNkhcV438F3 https://plus.google.com/113218107235105855584/posts/CNkhcV43...