Startup time of standalone .jar executable

[Michael Lindon]

I wrote a collaborator some clojure code which I distributed to them as a standalone jar file which they are executing with

java -jar mystandalone.jar

The problem is that this executable is called a great many times in their application and every time the 
executable is called there is a java/clojure startup cost. In fact the startup cost heavily domiantes the
run time, whereas executing the code in a repl is almost instantaneous.

How can I get around this? Would it be better to make a clojurescript executable?

[Mark Stang]

Planck?

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[John Gabriele]

One way around it might be to write your program as a separate service, running on the same machine, with it listening for connections on a network port.

[Luke Burton]

There isn't enough information here to really recommend a fix. But here are some general thoughts:

* If you're wondering whether there's a magic --fast-mode flag to make this problem go away, no, there is not. 

* Can you make this a whole lot faster? Probably, yes, but it will involve a lot of work. It would involve profiling where the startup time is being spent, picking appropriate GC and runtime parameters that prefer startup time over other considerations, etc.

* Is this an architectural smell? Absolutely. Executing any external binary "a great many times" is always going to be inefficient compared to letting the binary stay resident in memory. If performance is a concern you need to understand what the constraints are and design something that specifically addresses that.

Luke.

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to

clojure+u...@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.

To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.

[Duncan McGreggor]

Has the application owner defined an interface for long-running components? If not, maybe convince them to. Then they could just (.start yourCode) and then make whatever API calls you have defined, with zero start-up costs per-call from their side.

(This is what I do when integrating non-Clojure .jar files into Clojure applications -- I make them follow the Component[1] model and provide access to whatever connections, config, etc., they need via the Component library definitions.)

For your particular case, there are some fun ways in which you can manage state and respond to API calls in a long-running, in-memory Clojure app (in particular, core.async), so this could be a real treat for you :-)

Hth,

d

----
[1] https://github.com/stuartsierra/component

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to

clojure+unsubscribe@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.

To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.

[Mark Stang]

Depending what the processing is, ClojureScript could be a viable option.

As I mentioned earlier, "planck" has fast start times.

https://github.com/mfikes/planck

[Didier]

To answer your question, yes, ClojureScript startup times would be as fast as booting a shell command, a python script, etc.

To this end, you can use Planck like previously suggested, but I would recommend Lumo over it: https://github.com/anmonteiro/lumo

Lumo is a standalone ClojureScript interpreter, think of it as CPython for ClojureScript. It runs on Windows, Linux and MacOSX. The difference with Planck is that Lumo runs on Node.JS, while Planck runs on JavaScriptCore.

With lumo, you can use Node libraries from ClojureScript. It boots in 0.12 second on average.

With all self-hosted ClojureScript, you will be limited to pure ClojureScript, so even a macro which uses java dependencies to transform code will not work in self-hosted ClojureScript, which mean some ClojureScript library don't work.

Alternatively, just compile your code to javascript with the Java ClojureScript compiler, and have them call into the JavaScript itself.

clojure+u...@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.

To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to

clojure+u...@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.

To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.