Having been landed with a Ruby project, I have been sceptical about the decision to use Ruby due to performance.
I was excited to discover JRuby with its Java integration. This has made the project massively easier for me. And now I have just been totally tickled even more to discover that JRuby can be compiled down to Java bytecode .
With benchmark figures like so :
fib(30) Ruby: 1.67s
fib(30) JRuby interp (client VM): 3.93s
fib(30) JRuby interp (server VM): 2.28s to 2.08s
fib(30) JRuby compiled (client VM): 1.89s to 1.79s
fib(30) JRuby compiled (server VM): 1.66s to 0.86s
I am now getting very excited about our choice of JRuby here. Is there any disadvantages or reasons why you would not compile for the production release?
The distribution and installations would make that decision easier for me: as a sysadmin, I'd much rather distribute just a .JAR file that can run on many JRE's than have to distribute a working JRuby instance (which is different for different OSes, for example) and my source code. Plus, you have already demonstrated that AOT-compiled code is faster than the interpreted/JIT, so all the more reason to distribute the compiled version.
Ruby is very fast to develop in (if you are familiar with it's style).
Its not so fast to run, but this is not usually a big minus. Its plenty fast enough for most workloads, even large websites.
The decision ought not be based upon runtime speed - unless you have stats to say people are expected to be unhappy with performance - but rather ease of deployment.
If the deployment of Ruby applications has been achieved by your predecessors, then keep it Ruby.
If deploying to JVM is easier, go with that.
Related
I'm using NixOS as the distro on WSL (via the excellent setup provided by Trundle: https://github.com/Trundle/NixOS-WSL) and I'd like to install the racket package. If I run nix-shell -p racket, it dutifully downloads (or uses the previously downloaded) the pre-built binary and I can use it just fine. But if I add racket to the environment.systemPackages list in configuration.nix and try to nixos-rebuild test, it starts trying to build things from source. It fails when it gets to gtk (presumably because WSL2 doesn't yet support graphical applications).
Why the difference in behavior? Is there a way I can convince NixOS to use the pre-built racket when filling out the systemPackages? Happy to post my configuration.nix if it would help the diagnosis, though it's really not much of a departure from Trundle's.
When I configure like shown below and then compile, then the resulting qemu-arm performs many (about 20 to 40) times worse than the qemu-arm-static that came with Ubuntu 18.04.3 (AMD64).
I used the same branch (stable-2.11) as the version that came with Ubuntu.
How could I configure to get more performance?
./configure --static --target-list=arm-softmmu,arm-linux-user --extra-cflags=-O3 --extra-cxxflags=-O3 --extra-ldflags=-O3
I'm not sure if -O3 is a good idea -- you could check whether the Ubuntu package build uses that; I suspect it uses the default -O2 instead. In fact a good first step would be to build the Ubuntu package without any changes (ie get the package source with 'apt source qemu' and build it as an Ubuntu package) and check that it has the same performance you're seeing with the shipped binary version.
If the package you build doesn't have the same performance as the Ubuntu-built binary: then something weird is going on, which you'd need to investigate.
If the package you build does have the same performance as the Ubuntu-built binary (ie better than whatever you're building now): then the difference is somewhere in either how the Ubuntu packaging is configuring QEMU, or in the build environment it is using, or in some set of patches it's using that aren't in the branch you're currently building. You could try to narrow down what the difference is.
Other than that, a general note is that 2.11 is now a pretty old version of QEMU, and there have been performance improvements upstream since 2.11. But they're not 20-40x, so you should definitely try to identify why you're not getting the same performance as the Ubuntu package binary first.
We currently use cljsbuild to compile our clojurescript source into the assets used in production, but during development, we use lein-figwheel. Both cljsbuild and figwheel are constantly watching for changes of the source and recompile when necessary.
I was wondering, whether it's possible to use just one tool for both, preferably in the same process.
We're fine with switching tools, especially Figwheel Main. Each file change should just compile:
a js with advanced optimizations to be used in production
live reload the code in the browser as figwheel & figwheel main do it
I found this in the figwheel documentation, but it requires manual work like cleaning targets and running the build on demand with special options.
I recently switched from lein-figwheel to figwheel-main (using Clojure Deps in place of lein). Figwheel-Main is much simpler, easier & better (basically it is "Figwheel 2.0").
Figwheel-Main can be used for both the auto-reloading during development and for compiling a single my-app.js output file for deployment or testing. You can use either :whitespace or :advanced compiler optimization level to get a single static *.js output file. I use :whitespace to generate an output file for standalone testing purposes (in Docker with chrome --headless) or :advanced for the final production build.
As a side benefit, Clojure Deps is better than lein for managing conflicting dependency versions.
I created .exe file from .jar file .Now my client demands to run the application without installing jre in the sytem.I have heard that with bundled jre it is possible ...but i dont know how to bundle jre with .exe file..
The JavaFX is working on this. Here are the up-coming features in Java SE 7 u10:
https://blogs.oracle.com/talkingjavadeployment/entry/packaging_improvements_in_jdk_7#3
https://blogs.oracle.com/talkingjavadeployment/entry/packaging_improvements_in_jdk_7
I have used VMware ThinApp to do exactly what you are trying to do. It does cost money, but works extremely well. It allows you to roll up all the dependencies your application uses into a single executable that can then run on vanilla installations of Windows. It can be used for a lot more than just Java, and it does so by recording the changes you make to a system after installing your application + the JRE for example, and then wraps up all of those changes. It certainly simplifies application deployment, since the applications are now portable. I've even used it to roll up Visual C++ redistributables, and .NET as well. This certainly increases the size of the executable, but it's also convenient knowing the application will run successfully. See more info at http://www.vmware.com/products/thinapp/overview.html.
The open source Launch4j allows you to produce an exe with an embedded JRE. This SO article also discusses this topic. Caveat: I've had very good success with Launch4j, but never used the embedded JRE feature.
I'm looking for some build automation tool for JRuby project. Result of this project should be some library that can do stuff. I need to use some Java libraries but I want to work with Ruby. So that's why JRuby.
In this stage, I'm looking for build automation tool that can handle dependencies and download them from remote repository.
I could use Maven for this, but I'm interested in other alternatives that could be more fun to work with.
So yeah, if you are looking for something sexier than Mave, SBT is good option.
Other options are:
Gradle - http://www.gradle.org/ - if you want Groovy rather than scala orientation.
Or Gant - http://gant.codehaus.org/ - for some more in the lines of Ant.
Buildr - http://buildr.apache.org/ - Is another interesting project
I also came across this dead project - http://raven.rubyforge.org/ - But I wonder if something new came to tackle the same item, i.e. using Rake , the ruby build tool, to build java as well.
From a dependency management perspective only, jbundler is a bridge between Maven and bundler that can help you manage your dependencies, whether they are gems or maven artefacts.