I find java starts up and runs practically instantly for me - but javac takes a few seconds, and ant makes it slower again. It's only a few seconds, but my edit-compile-test loop would be smoother without it. :-)
BTW: I've already used vim's ":make" with ant.
Is there a way to speed up javac and/or ant? I'm thinking of special switches, or tricks? Or maybe an alternative java compiler (I'm using 1.6, in linux)
Eclipse does that for you ... but it's probably a bit big as a "patch" for your problem.
That aside, you can roll your own compiler plugin. There are two approaches:
Run the java compiler from within ant (instead of creating a new process). Not sure if ant already does that; if not, that will save you a bit of time. Look at the Java 6 compiler API for details.
Run javac in a server process which listens for options on a socket. In ant, send the process the command line and wait for the output to be sent back. Saves you starting a new process all the time.
Try to use the eclipse compiler. Unlike the original javac, the Eclipse compiler is pretty good at "ignoring" errors, so it can produce class files even when they contain errors. That doesn't seem to mean much but it allows you to compile all the time in the background. When you do your last save (wrapping everything up), the compiler will have been able to compile everything else and will just have to look at a single file.
Google found these two (I haven't tried either yet)
javac -J-client -J-Xms100m -J-Xmx100m <src>
JBrownie "monitors Java sourcecode and automatically recompiles any files found changed" along the lines of Aaron Digulla's (2)
I can strongly recommend using a suitable IDE with Java as the productivity increase with using an editor which knows about your program is immense. Think of "goto the line containing the defintion of the variable/class/field the cursor is on", "rename this class and all references to it", and all other kinds of nice things. If you are annoyed with the time it takes to invoke Java, you might be ready :)
You may want to have a look at JavaRebel
I point all of my output files to a ramdisk that I create with this utility. It speeds up builds a fair bit (Though not to a magical extent) since almost everything is in memory. It's most noticeable when doing a 'clean' build which becomes almost instant.
Related
I try to run my JAVA application with JVM arguments in Eclipse.
I noticed that a "-noverify" String is appended each time at the end of the parameters, which makes them unusable because I need that as a patch to my config files. (And the program say: "/home/user/config.properties-noverify" isn't exists.)
The arguments are:
-Djava.security.egd=file:/dev/./urandom -Dspring.config.location="/home/sige/guezbin/application.properties" -DconfigPath="/home/sige/eclipse-workspace/ImgCompr/config-default.properties"
I develop under Ubuntu. With Eclipse version 4.8.
I Googled a lot but I didn't find any answers.
Can somebody explain to me what is this and how can I use it in a proper way?
The JVM checks the byte code of the compile classes it is about to load to see that it is well behaved. This is an essential step for executing untrusted code.
Unfortunately this takes time and for a very large application like Eclipse this may increase the startup time quite a bit. The "-noverify" flag turns this off.
It sounds like that you need a space after your own string so the "-noverify" flag is not concatenated. If you cannot do this, then make a work around like "-Dignore" which becomes -Dignore-noverify and then your code should work.
I have created a Java program which reads encrypted files from local system and does some processing. Actually I have 20 files to read so I have used threading mechanism to speed up the program execution.
When I run the program in Eclipse it takes more than 30 minutes to complete the execution, whereas if I make a runnable jar and execute the program using command prompt, it takes less than a minute.
Why does running programs in Eclipse take more time than running them in command prompt?
Eclipse's Console view that captures System.out is notoriously slow compared to the regular stdout of the command line. Whenever there is a lot of printing happening in the program, it is to be expected that the program will run significantly slower from Eclipse.
But anyway, unless you are writing a program designed to integrate with other programs via Unix pipes, you should minimize the printing as it will kill performance even at the command line.
There are some typical mistakes:
Maybe you are executing your program in Debug mode.
Try to use Run (play symbol inside a green circle) instead of Debug (a green bug)
Maybe you are executing your program with a different JVM
Take a look in Project Properties->Java compiler, Window->Preferences->Java->Compiler and Window->Preferences->Java->Installed JREs
The output and input interactions with Java Console of Eclipse JDT differ on performance than standard console.
Ensure that you use the Run action in Eclipse, and not Debug, as the latter really has measurable difference, especially if you use conditional breakpoints.
However, I remember having less significant differences arising from the use of the Debug.
I have just did an experiment for you and did not saw so significant difference.
I created class that calculates sin() 100000000 times.
This program ran ~15 seconds under eclipse and ~14 seconds via command prompt.
So, here are the reasons for slowness in your system I can see at the top of my head:
Be sure that you are not running under debug. Use Run option, not Debug.
Be sure that you do not have some coverage/monitoring developers tools on under eclipse. For example YourKit, Emma etc.
Be sure that your program does not produce significant prints to the console.
Check that you have enough heap memory when running under eclipse
Changing jdk 6 to jdk 7 worked perfectly for me.
Window->Preferences->Java->Installed JREs
Is there some way to get reasonable (not noticeable) starting times for Java, thus making it suitable for writing command line scripts (not long-lived apps)?
For a demonstation of the issue, take a simple Hello World program in Java and JavaScript (run w/ node.js) on my Macbook Pro:
$ time java T
Hello world!
real 0m0.352s
user 0m0.301s
sys 0m0.053s
$ time node T.js
Hello world!
real 0m0.098s
user 0m0.079s
sys 0m0.013s
There is a noticeable lag with the Java version, not so with Node. This makes command line tools seem unresponsive. (This is especially true if they rely on more than one class, unlike the simple T.java above.
Not likely, only thing you might be able to try is a different implementation of the JVM, but that probably won't change. Most Java apps are (relatively) long lived though and possibly interactive, which means the JVM startup time becomes lost in the noise of normal uses.
Have you actually tried timing a Java command-line app called repeatedly, though? I would expect after the first incarnation for the start-up time to be alleviated somewhat by the library classes being in the file system cache.
That said, yes, the Java platform is not one of the simplest and in any case you're not going to compete with a small native executable.
Edit: as you say that the timings above are for "warmed up" calls, then a possible workaround could be:
write the gubbins of your commands in Java
write a simple local continually running "server" that takes commands and passes them to the relevant Java routines
write a simple native command-line wrapper (or write it in something that's fast to start up) whose sole raison d'être is to pass commands on to the Java server and spit out the result.
This ain't nice, but it could allow you to write the gubbins of your routines in Java (which I assume is essentially what you want) while still keeping the command line model of invocation.
As others have said, the plain answer is just "not really". You can possibly make minor performance improvements, but you're never going to get away from the fact that the VM is going to take a while to start up and get going.
Make sure you haven't got the server VM selected for apps like this - that's one thing that really will increase the start up time.
The only real way round it is to compile Java to native code, which you can do with GCJ - so if you must write these apps in Java and you must have them faster, that might be a route to look down. Bear in mind though it's not that up-to-date and maintenance on it largely seems to be dying out too.
Haven't tried it yet but might be worth looking at nailgun. It will run your Java programs in the same JVM, so after "warming up" should be pretty fast. A "hello world" example goes from taking 0.132s to taking 0.004s
http://www.martiansoftware.com/nailgun/background.html
You can get a small speed-up with class data sharing https://rmannibucau.metawerx.net/post/java-class-data-sharing-docker-startup
A much bigger speedup should come from doing ahead-of-time compilation to a static binary using GraalVM native-image, although it's still tricky to use. A lot of libraries haven't been made compatible.
I've got a (fairly typical) setup at the moment of launching my Java application through a batch file calling the jar file with appropriate parameters, which most of the time works absolutely fine. However, I'd like to be able to deal with any errors that might occur nicely.
At the moment I've got something like
java -Xms1024m -Xmx1024m -jar Quelea.jar
IF NOT (%ERRORLEVEL% == 0) cscript MessageBox.vbs "Application failed to start."
The last line is basically the first answer on this question.
I'd like something a bit more fully featured though, even if it's a case of capturing the output from launching the process and then dumping it in the message box (ok, it's not pretty but it shouldn't appear to start with and when it does appear that then gives me some immediate debugging information without having to ask the user to grab out log files!) Or are there any other approaches that people use in similar situations?
I'm not talking about exceptions thrown in my code (which I deal with once the application starts) I'm talking about hard errors that prevent it starting such as using an old JRE version, not having enough memory to reserve for heap, that sort of thing.
I suggest using a Java executable wrapper. I like the following, but there are others.
http://launch4j.sourceforge.net/
I did some simple function call and string operation in a loop, the java program runs much faster under command line than launching ( Run as... ) from eclipse...
6 lines of output were printed, each line is around 120 characters.
each line is a perf result ranges from 50ms to 300ms.
The total time is a little more than 2 seconds.
"much slower" here means, for certain operations ( function call ), I see 20ms vs 300 ms.
After running on console once, the speed on eclipse catches up!
After I change and build the code in eclipse, the speed on CL will drop if I don't rebuild it with command line.
Looks like some hotspot information is only generated with CL...
Maybe it is just the eclipse console that is slower than your operating systems console?
Plus, at a total runtime of ~2 seconds, your benchmark probably is just super inaccurate.
Most likely the culprit is memory usage as a result of Eclipse loading, with the possibility that Eclipse is also doing something additional to the executable like swapping class loaders, or starting the java debugger.
I would say the most likely answer however is simply: Eclipse uses a lot of resources, especially memory, and is starving the system a bit, leading to swapping, and decreased performance. YMMV, and there's no guarantee I'm right without seeing your system, it's just my best guess.
I do agree with other comments that Eclipse is doing something when running the application and printing the console.
Eclipse has its own compiler (usually referred as Eclipse JDT) which supports incremental compilation. There is a possibility that the binary compiled by Eclipse is not optimized as it is compiled by javac.
These two compiler serves different purpose, JDT mainly enable Eclipse to provide state-of-art refactoring and auto-completion, and javac spends a lot of effort doing optimization.
I would say it's understandable that the application would run slower with all the Eclipse baggage underneath. Eclipse spawns the JVM process as a child and I am sure still does its own 'magic'.