4 ms·

And if you use Spring, then the start up time is even worse! I do wish the JVM had an option that would make it start up instantly, even if it meant that the pr

And if you use Spring, then the start up time is even worse! I do wish the JVM had an option that would make it start up instantly, even if it meant that the program would run slower. I wonder if the slow startup time has to do with the JVM having to dig through .jar files to find stuff. I'm also surprised that there isn't a way to cache the machine code generated by the jit so that the machine code doesn't have to regenerated on every run. It seems very strange to me that Java was invented by a Unix company, and yet it seems rather Unix-hostile. For the stuff that I'm working on, the 1 second startup time is no biggie though. One CLI thing I wrote, for instance, crunched on genomics data for 3 minutes before finishing. By tuning tight loops and the like, I was able to get that down to 15 seconds, but even so, the extra second there is no biggie. Except for when the user uses the "--help" option. That extra second is tedious.

6ren 15y ago
Yeah, I'm puzzled by them not caching, e.g. they could copy an image of the JVM in its starting state. Maybe the "unix hostility" is due to platform agnosticism ("run everywhere"), servant of two (or three) masters. e.g. issues in file libraries and AWT. But py/rb/perl manage this OK... so idk. BTW: bad practice to split up functionality (and loses many benefits of Java), but a performance solution would be a script that handles the "--help", and for anything else starts the JVM.
- nessus42 15y ago
  I've actually used that hack for "--help", but I mostly use command line parsing libraries (e.g., JCommander) that generate the usage message for you. The users will just have to put up with the slight delay....
  - 6ren 15y ago
    Yeah, it's a pain to setup and maintain. Bizarre idea: a source transformer that knows about a CLI parsing library, to detect your usage of it and create the help option in a scripting language - and also provide the packaging (for the scripting language to start the JVM). Like Google's GWT for compiing a Java subset to JavaScript. Seems a bit of overkill, but I like the idea of a transformation operating above the level of one language... I suppose the logical conclusion is compilation of arbitrary Java source to a scripting language, according to the performance characteristics required. It's nice that it would retain semantics and be transparent to the user, while rebalancing performance trade-offs.
    - nessus42 15y ago
      Nooooooooooooo! We've switched largely to Scala! (But we're sill stuck with Java for GWT. :( )
      - 6ren 15y ago
        Sorry, I don't follow. Doesn't Scala have the same JVM startup delay as Java? Can do the same thing for Scala.
        nessus42 15y ago
        Yes, Scala is a JVM language, and all JVM languages that I am aware of have this start-up delay. One of the advantages of the JVM is that many different languages can interoperate easily, but if you do source-to-source translation to a non-JVM language, then the origin languages (e.g., Java) that have this extra support become preferred, and thus discourage the adoption of the better languages. E.g., GWT prevents us from completely migrating to Scala. It seems as if it would be better to have have a JVM byte code to Python byte code translator, or something like that, if such a thing is possible. But I should think that it would be even better and easier to just have a version of the JVM (or an option on the JVM) that starts up much faster. If you're happy with just Java, doesn't BeanShell start up more quickly? (I don't know, because I've never used it.)
        6ren 15y ago
        > JVM byte code to Python byte code translator Yes; or a JVM that starts up faster, and split the code between them in the same way. I'm assuming there's a fundamental trade-off between startup delay and average speed, or we'd have had an instant option long ago. Um, if the problem is loading etc jars, this mightn't work. But one could still detect byte-code calls with hard-coded string arguments (for "--help" and text) and compile that to python.

6ren 15y ago

Yeah, I'm puzzled by them not caching, e.g. they could copy an image of the JVM in its starting state. Maybe the "unix hostility" is due to platform agnosticism ("run everywhere"), servant of two (or three) masters. e.g. issues in file libraries and AWT. But py/rb/perl manage this OK... so idk. BTW: bad practice to split up functionality (and loses many benefits of Java), but a performance solution would be a script that handles the "--help", and for anything else starts the JVM.

nessus42 15y ago
I've actually used that hack for "--help", but I mostly use command line parsing libraries (e.g., JCommander) that generate the usage message for you. The users will just have to put up with the slight delay....
- 6ren 15y ago
  Yeah, it's a pain to setup and maintain. Bizarre idea: a source transformer that knows about a CLI parsing library, to detect your usage of it and create the help option in a scripting language - and also provide the packaging (for the scripting language to start the JVM). Like Google's GWT for compiing a Java subset to JavaScript. Seems a bit of overkill, but I like the idea of a transformation operating above the level of one language... I suppose the logical conclusion is compilation of arbitrary Java source to a scripting language, according to the performance characteristics required. It's nice that it would retain semantics and be transparent to the user, while rebalancing performance trade-offs.
  - nessus42 15y ago
    Nooooooooooooo! We've switched largely to Scala! (But we're sill stuck with Java for GWT. :( )
    - 6ren 15y ago
      Sorry, I don't follow. Doesn't Scala have the same JVM startup delay as Java? Can do the same thing for Scala.
      - nessus42 15y ago
        Yes, Scala is a JVM language, and all JVM languages that I am aware of have this start-up delay. One of the advantages of the JVM is that many different languages can interoperate easily, but if you do source-to-source translation to a non-JVM language, then the origin languages (e.g., Java) that have this extra support become preferred, and thus discourage the adoption of the better languages. E.g., GWT prevents us from completely migrating to Scala. It seems as if it would be better to have have a JVM byte code to Python byte code translator, or something like that, if such a thing is possible. But I should think that it would be even better and easier to just have a version of the JVM (or an option on the JVM) that starts up much faster. If you're happy with just Java, doesn't BeanShell start up more quickly? (I don't know, because I've never used it.)
        6ren 15y ago
        > JVM byte code to Python byte code translator Yes; or a JVM that starts up faster, and split the code between them in the same way. I'm assuming there's a fundamental trade-off between startup delay and average speed, or we'd have had an instant option long ago. Um, if the problem is loading etc jars, this mightn't work. But one could still detect byte-code calls with hard-coded string arguments (for "--help" and text) and compile that to python.