speeding up google closure compiler jar - java

The Google Closure Compiler for JavaScript is quite speedy when I use it online; however, it takes up to 10 seconds to run from the commandline (java -client -jar path/to/closure.jar options...).
Is there any way to reduce this to the same times as the web app (3 seconds max)? I cannot use the web app because my company requires all builds be able to work without an internet connection.
I suspect this is mostly startup time (why I added the -client tag), but I don't know.

I would suggest looking into Plovr[1]. You need only start it once, after which point it will monitor changes in your dependencies and recompile as needed. You can use the same config on your build server to create the output without starting it as a service.
http://www.plovr.com/

Related

Expedite the develop / deploy / run cycle with Spring, Maven and Wildfly

I've just recently entered the Java world for a client of mine. I have 18 years experience as a .Net developer, but the Java side is new.
Coming from .Net, I'm used to expecting to be able to make a code change, compile my code and run it with a debugger attached all usually within sub 30 seconds, maybe 1 minute on large projects needing a full recompile.
I'm finding my current process with this Java project is taking me upwards of 5-6 minutes. Because of the long time and multiple steps, I find myself starting on other tasks or losing track of what I was doing.
Here is my current process for making a change and testing it:
Make code change
(~200s) Recompile code with Maven on the main Maven module mvn clean install. If I do -DskipTests I can save about 60 seconds here.
(~5s) Stop Wildfly server
(~5s) Copy .war file from myproject\target\myproject.war to c:\wildfly\standalone\deploy\
(~90s) Start Wildfly server c:\wildfly\bin\standalone.bat
Re-login to application (my session expired)
Attach debugger
Again, it is not only the amount of time required for each of these steps but the fact that there are so many steps and the waiting time in-between each makes for distraction as well - after all, who is going to sit and stare at a screen for a 3 minute compile? Whatever I go off to do, I am surely not going to return to that screen at the exact moment the compile is complete. There is going to be wasted time in there.
Further more, I'm repeating this process every time I want to make a single code change.
Is there a way to streamline this process? I.e.:
Is there a way to join some of these steps
Can I speed up the Wildfly boot process?
What will speed Maven up?
Can I do something like "Edit & Continue" which exists in .Net (i.e. live code changes).
Is there a way to get around having to have Wildfly reinitialize anytime I deploy a new war?
Disclaimer: My answer includes processes I personally use, thus it may not be the optimum or most popular solution. Anyway, these things tend to be bound to developer's personal preference.
Find below some recommendations that could speed up the development process.
Use a proper IDE for Java development
Using a popular java IDE can make development faster as it supports integration with build tools(Maven), Version Control Systems, Application Servers(Wildfly) and much more.
Popular choices are Eclipse, IntelliJ, Netbeans and much more.
Fast redeployment
As I said above, a proper IDE would support integration with application servers, Wildfly for your case. By using a Wildfly IDE plugin, you can speed things up as you do not have to wait for app server to boot every time you make a code change. IDE starts once the server and then applies your changes to the running instance.
Personally, I also prefer to use a standalone Wildfly installation instead of integrating it with IDE. To achieve fast redeployment I use hotswap agent. Note that you have to install DCEVM, an alternate JVM which however is not interfering with your main JVM.
Finally, to conclude it is understandable that you make a big turn from .NET to Java and you may feel lost at some points. I would advise to spend some time setting up your environment, and once you have finalised it and you feel comfortable, development will become much easier.
Why stop, move the archive and re-start the server ?
Check out the following maven plugin which will allow you to automate at least that part of it..
https://docs.jboss.org/wildfly/plugins/maven/latest/examples/deployment-example.html

How to Profile Execution of RDF4J Server?

As I indicated in another post, I'm having trouble with some SPIN constructors taking an excessive amount of time to execute quite limited data. I thought I'd take a different approach and see if I can profile the execution of the constructors to gain insight into where specifically they are spending excessive time.
How do I go about profiling the execution of constructors under RDF4J Server? I'm instantiating via SPARQL update (INSERT DATA) queries. Here's the System Information on RDF4J workbench:
I've attempted to profile the Tomcat server under which the RDF4J Server runs using jvisualvm.exe, but I have not gained much insight. Ideally, I'd like to get down to the class/method level within RDF4J so that I can post a more detailed request for help on my slow execution problem or perhaps fix my queries to be more efficient themselves.
So here's the version of Java Visual VM:
RDF4J is running under Apache Tomcat 8.5.5:
I can see overview information on Tomcat:
I can also see the monitor tab and threads:
HOWEVER, what I really want to see is the profiler so that I can see where my slow queries are spending so much time. That hangs on Calibration since I don't have the profiler calibrated for Java 1.8.
This attempting to connect box will persist indefinitely. Canceling it leads to the Performing Calibration message which doesn't actually do anything and is a dead-end hang requiring the Java VisualVM to be killed.
After killing the Java Visual VM and restarting and looking at Options-->Profiling-->Calibration Data, I see that only Java 7 has calibration data.
I have tried switching Tomcat over to running on Java 7, and that did work:
The profiler did come up with Tomcat:
However, when I tried to access the RDF4J workbench while Tomcat ran on Java 7, I could not get the workbench running:
So, I'm still stuck. It would appear that RDF4J requires Tomcat running under Java 1.8, not 1.7. I can't profile under Java 1.8.
I have seen other posts on this problem with Java VisualVM, but the one applicable solution seems to be to bring everything up in a development environment (e.g. Eclipse) and dynamically invoke the profiler at a debugger breakpoint once the target code is running under Java 1.8. I'm not set up to do that with Tomcat and RDF4J and would need pointers. My intention was not to become a Tomcat or RDF4J contributer (because my tasking doesn't allow that... I wouldn't be paid for the time) but rather to get a specific handle on what's taking so long for my SPIN constructor(s) in terms of RDF4J server classes and then ask for help from the RDF4J developer community on gitub.
Can Java VisualVM calibration be bypassed? Could I load a calibration file or directory somewhere for Java VisualVM to use instead of trying to measure calibration data which fails? I'm only interested in the relative CPU loading of classes, not absolute metrics, and I don't need to compare to measurements on other machines.
Thanks.

javaws.exe poor performance compared with java.exe in java8

You have to contract for supporting non public available Java releases with Oracle for example Java6 ended with 1.6.0_45 publicly but with support you can use 1.6.0_80. Our aim is to stay supported and public available java platform. Therefore we want to migrate our jnlp based RIA application from Java6 to java8 platform. In migration testing we have experienced performance problem. We try to simulate this problem in Java 8 poor GUI performance compared to Java 6 but we realize that the problem not related the that question.
After the introduction, in order to find out the root cause of problem we profiled the application with java mission control(jmc) bundled with jdk. when we profile application launched at workspace we cannot see any performance degradation. And then we realize that problem occurs only JAVAWS environment. Our application runs as expected at java environment but in javaws environment some GUI's are really slow , it adds 6 seconds more to response time.
My first question is that how we profile java application launched by javaws? Because to use jmc we need to set some JVM arguments (java-vm-args="-XX:+UnlockCommercialFeatures -XX:+FlightRecorder") but javaws doesn't support this JVM parameters. You can find supported list at here
My Second question is that why application doesn't run identical at both environment(java and javaws)? We examined signed and unsigned version of our application and both have same situation. By the way our application uses all-permission.
You can pass any JVM arguments you want to javaws by typing them in:
Java Control Panel > Java > View > Runtime Parameters
As for the poor performance, are you referring to application load time? or is it also slow after the applicatio is started?
If you're talking about load time, then yes javaws is slower (about 3-5 seconds slower) because it has to contact Internet to check if your jar files are black listed or if the certificate is expired. I'm not sure exactly what it is doing in these few seconds but I agree that it is disappointing performance hit and I hope someone can shed more light on it.
Thanks Saeid. Problem is determined. We profiled finally and we found that javaws consume long time to load resources e.g. icons, images. to make a solution we cached the resources and for absence images we return a empty image.
You can see this at
To profile application launched by javaws we make a solution following steps in ubuntu
1. move java executable javam
2. create a script file named java and insert following script
#!/bin/bash
/full/path/of/javam XX:+UnlockCommercialFeatures -XX:+FlightRecorder "$#"
3. run application and check java is launched by ps -ef | grep javam
4. run jmc and profile it.

Websphere Eclipse plug-in and Ant dev environment setup

We use Eclipse to develop and Websphere 7.0 to run our code. We use a plugin for Eclipse which allows you run run a copy of WAS locally and integrated with Eclipse. This works but it's not great. Each time I have to make a change I have to run my Ant script (5 mins.) then do my install into WAS and restart the app in WAS (another 5 mins). This is not efficient (actually it's downright annoying!)
What's the best setup Websphere allows, ignoring for a min what is easy to do etc. I want to know what to aim for. Obviously I would love to be able to save in eclipse then go to my browser and refresh the screen, am I mad?
I have looked at this about using Websphere's native Ant, and it is one avenue but I'm sure there's better.
Can I use jpda like I do when starting Tomcat and develop directly in the code? I will still need Ant when doing a full re-build as I have some Java file generation to do but for the in-process builds???
Thanks-in-advance for any and all help.
There is not just one straightforward single best answer as it depends a lot on the application you are doing.
If you rely on ant to make the build and that takes five minutes for any update you do then it may be hard to get away from that. You may not have to do it like that, you may be able to do incremental compilations (only compiling the updated classes) and that should be a lot quicker (but since I don't know anything about your application it is hard for me to tell you that this is a way forward for you). The updates you make in WAS and if that requires a total restart of the application depends on many different factors.
If I update only a jsp file it usually does not require a full application restart, but if you start to update the classes and definitely when you update your web.xml or something like that, a full restart of the application may be required.
The time it takes for you to restart your application depends a lot on what actions your application will perform when you start it up. If you have an application that takes five minutes to start up, then every restart will cost a lot. Is there something you can do to reduce the restart time in certain configurations? Can you divide your application into separate deployables to reduce the startup time for each individual application?
It all depends on your needs and requirements.
We used to have long startup times for our local servers, but since we had upgraded disks (SSD-disks) and enough memory the server startup time has been reduced by 80-90%.

Websphere Application Server - What on earth will it take to start any fast?

I am using Rational Application Developer v7.0 that ships with an integrated test environment. When I get to debugging my webapp, the server startup time in debug mode is close to 5-6 minutes - enough time to take a coffee break!
At times, it so pisses me off that I start cursing IBM for building an operating system instead of an app server! Spawning 20+ processes and useless services with no documented configuration to tuning it, to starting any faster.
I am sure there are many java developers out there who would agree with me on this. I tried to disable the default apps and a set of services via my admin console, however that hasn't helped much.
I have no webservices, no enterprise beans, no queues, just a simple web app which requires a connection pool. Have you done something in the past to make your integrated test environment, start fast in debug mode and there by consume less RAM?
UPDATE:
I tried disabling a few services (internationalization, default apps etc...) and now the WebSphere server went from bad to worse. Not only doesn't it take horrifying startup time, it keeps freezing every now and then for up to 2 minutes. :-( Sounds like, optimization is not such a good thing, always!
The best way to debug server code is to use remote debugging.
First you need to add the following to the JVM params in the server start script:
-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005
This will cause the JVM to listen on the specified port, then from your IDE you can start a remote debug session against that port and debug as if the code was running in the same process.
Working this way prevent you restarting the server so frequently and hence side-steps your problem with Websphere's start-up time.
You can get some odd results if the binaries on the server and the source in the IDE get out of sync but on the whole that's not a problem.
One of the main reasons is that you have a large application with many modules, classes, manifests, XML descriptors so on, and the fact that Websphere application server start up process is single threaded per se (thus each application may be started in a separate thread if they has equal weight). One other reason is that the Eclipse EMF and JST frameworks are very I/O intensive during startup and publish/deploy.
One other reason for the tedious start up is the annotation scanning which will occur during publish/deploy. This annotation scanning can be controlled and modified in a various ways. Look at this site:
http://wasdynacache.blogspot.se/2012/05/how-to-speed-up-annotation-processing.html
First of all, examine and evaluate your hardware, both CPU, memory and HDD. Is your processor/s running 100% for a long time during start up? If so, the processor may be too weak. Is paging occur? then you may have to put in some more RAM. The Websphere/eclipse JST and EMF frameworks are very I/O intense so you should consider to invest in a SSD disc. You should also make sure that other processes on your machine (virus protection software etc.) don´t steal hardware resources from the Websphere java processes.
So for the hardware:
1. Processor - a pretty fast one, since the publish and the startup is mostly singlethreaded you do not need that many cpu cores
2. Memory - You will at least need 512Mb of physical RAM, this depends of the size of your application of course.
3. Storage - I would definitely go for a fast SSD since the underlying eclipse framework is I/O intensive.
Here are some tricks to reduce the footprint of the start up phase. Please before applying these settings make sure that you record a baseline start up so that you can observe the difference in start up, i.e. the reduced start up time.
JVM args : -Xverify:none -Xquickstart -Xnoclassgc -XX:+UseNUMA -XtlhPrefetch -Xgcthreads4 (I got 4 virtual processors installed on my machine)
Extend the heap size to match the demands of your application.
Disable the autostart of the application to reduce publish time.
Disable PMI and unnecessary tracing.
Profile your application during startup and fix bottlenecks if found any.
Other JVM arguments that may gain performance:
com.ibm.cacheLocalHost=true
com.ibm.ws.classloader.zipFileCacheSize=512
com.ibm.ws.classloader.resourceRequestCacheSize=1024  
com.ibm.ws.management.event.pull_notification_timeout =20000
com.ibm.ws.amm.scan.context.filter.packages=true
org.eclipse.jst.j2ee.commonarchivecore.disableZip=true
Jvm arguments that will make the Websphere application server to stop immediately:
com.ibm.ejs.sm.server.quiesceTimeout=0
com.ibm.ejs.sm.server.quiesceInactiveRequestTime=1000
Webcontainer properties:
com.ibm.wsspi.jsp.disableTldSearch=true
com.ibm.wsspi.jsp.disableResourceInjection=true
JVM arguments that may be specified eclipse.ini (Note that the heap parameters is configured according to the conditions of my environment)
-Dcom.ibm.ws.management.event.max_polling_interval=5000
-Xquickstart
-Xverify:none
-Xmxcl25000
-Xjit:dataTotal=65536
-Xcodecache64m
-Xscmx48m
-Xnolinenumbers
-Xverify:none
-Xmnx64m
-Xmx1446m
-Xmnx64m
-XX:+UseCompressedOops
-XX:+UseNUMA
5 to 6 mins is not normal. I use RAD and WAS everyday and get decent startup times. Which version of WAS are you running and how much RAM do you have?
If you share several workspaces and projects for a same WAS profile, consider creating a new WAS profile for your workspace.
You probably tried that but here's a simple check list of things to try on first hand. Make sure that your server settings in RAD has the following options enabled:
Optimize server for testing and developing
Run server with resources on the workspace
Minimize application files copied to the server
Uncheck "Enable universal test client" if you don't need it.
In the admin console you can verify some server settings such as
Run in development mode
Parallel start
Start components as needed
You can also uninstall the ivt app that comes installed by default when creating a new WAS profile. Then the usual things such as a drive that is not too fragmented and a pagefile size that is properly set.
And one last thing that you probably know already, republish to your server instead of restarting it.
That's one reason why Spring was born.
You don't even have to give all the niceties like JMS, remoting, etc. You'd be better off with Tomcat, ActiveMQ, and OpenEJB.
Anything but WebSphere.
There's some hints and tips for tuning RAD 6 on developerworks that may help, many of these also apply for RAD 7.
I have seen a similar list for RAD 7, I'll post it if I can find it.
I did find some tuning tips for Portal on RAD 7.
I would say my experience with the test environment has been suboptimal. I now tend to use Tomcat/Pluto configured for remote debugging with an External launch configuration to manage it from within bare Eclipse and rely on having appropriate JNDI configurations to abstract the underlying server.
If you are coding to the relevant APIs it shouldn't matter for development purposes that you're not on Websphere. If you do have a Webpshere specific issue you can always crank up the beast to debug it.
If you have no EJBs, no JMS, etc., just deploy under a standalone servlet container such as Tomcat or Jetty, you'll be amazed how fast it is :-), being ironic here but it's true!
If the connection pool really is the only appserver feature you use then why don't you simply use apache commons dbcp (http://commons.apache.org/dbcp/) drop webfear alltogether and use jetty instead. That should reduce your startup time to about 5 seconds. You can then later easily switch to websphere again for your production environment if you should really feel the need to.
WAS V7 addresses some of these problems by allowing you to configure what starts up when the app server starts up.
So if and when you migrate to WAS V7 you might seem some improvements in this space.

Categories