Fork me on GitHub

I’m seeing an unnerving difference between my AOT code and my non AOT code


java.lang.IllegalStateException: ABORTED
	at org.eclipse.jetty.server.HttpChannelState.sendError(
	at org.eclipse.jetty.server.Response.sendError(
	at ring.adapter.jetty9$proxy_handler$fn__85201.invoke(jetty9.clj:59)
	at ring.adapter.jetty9.proxy$org.eclipse.jetty.server.handler.AbstractHandler$ff19274a.handle(Unknown Source)
	at org.eclipse.jetty.server.handler.HandlerList.handle(
	at org.eclipse.jetty.server.handler.HandlerList.handle(
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(


there are http2 errors that happen only if i am compiling a main and building into an uberjar


those are two orthogonal things, aot compiling and running from an uberjar

☝️ 1

build an uber jar without aot compiling and see if it still happens


How can I do that? I don’t care that much about AOT, i just need the jar to run my main ns


my wild guess would be it is also happening when you run in the repl without aot compiling, the output is just being directed somewhere else so you aren't seeing it


the other visible result of the error is that the server doesn’t accept any requests no matter what, so i don’t think it is happening in dev silently


(I am assuming when you say "non aot" code you mean running your code at dev time in the repl)


Does anyone recommend a Clojure/java lib to query WHOIS?


Perhaps not the answer you're looking for, but you could just use http. For example, I don't know anything about this particular service. This was just the top search result


silly suggestion maybe, but you can always call dig over


Is clojure.test.check.random available as a separate library somewhere? I could’ve sworn it was but I’m starting to wonder if I just imagined it.

Alex Miller (Clojure team)18:11:57

doesn't ring a bell, but feel free to use it if you obey the license and preserve the copyright


Great. Thanks!


On destructuring and speed: I see the following on My Machine(TM):

user> *clojure-version*
;; => {:major 1, :minor 10, :incremental 1, :qualifier nil}
user> (def m {:a 1})
;; => #'user/m
user> (criterium.core/quick-bench (let [{:keys [a]} m] a))
Evaluation count : 16846224 in 6 samples of 2807704 calls.
             Execution time mean : 28.819219 ns
    Execution time std-deviation : 0.805046 ns
   Execution time lower quantile : 27.750979 ns ( 2.5%)
   Execution time upper quantile : 29.760922 ns (97.5%)
                   Overhead used : 7.487563 ns
;; => nil
user> (criterium.core/quick-bench (let [a (get m :a)] a))
Evaluation count : 46207716 in 6 samples of 7701286 calls.
             Execution time mean : 5.958368 ns
    Execution time std-deviation : 0.436972 ns
   Execution time lower quantile : 5.618597 ns ( 2.5%)
   Execution time upper quantile : 6.663388 ns (97.5%)
                   Overhead used : 7.487563 ns

Found 1 outliers in 6 samples (16.6667 %)
	low-severe	 1 (16.6667 %)
ie, for this very small example on this clojure version, there almost a 5x penalty for using destructuring rather than a get. Are there any plans to address this (or have it been addressed in 1.11 with the new destructuring work that @fogus did), or should one just avoid destructuring whenever performance is critical?


try (m :a) 🙃


(m :a) is 50% faster than (:a m)


Nothing wrong with using get. If performance matters and destructuring costs you more than you want to pay, I think you have the answer to your question. 🙂


Sure, but I tend to like destructuring, especially in fn params, and it would be nice if I could use it also in performance sensitive code.

Ben Sless06:11:09

You could always write your own clever version of destructure and hope for the best, but that's cooking with gas 🙂

Ben Sless06:11:11

It's also useful to know what's your performance budget. you can gain ~10-20 ns per key if you hand-tune your code. If your budget is under 1us, go for it, if it's 1ms, I wouldn't bother


for, uh, reasons, the same destructuring code is generated anywhere destructuring is used (fn paramters, let bindings, etc) and to support map rest parameters to functions, there is a extra check when map destructuring


so for example this works:

user=>  (def m (list :a 1))
user=> (let [{:keys [a]} m] a)


and the reason that works is because the code used to support

user=> ((fn [& {:keys [a]}] a) :a 1)
is also generated for let bindings where there is no rest


(rest, varargs, whatever)


so destructuring is doing more than just get, so it will be slower


Yeah, I kinda understand that destructuring does more, but I would perhaps have hoped that since some of it happened at compile time, there was a possibility of analyzing the destruction and doing some smart stuff on the simpler cases?

Alex Miller (Clojure team)21:11:52

still a potential place for more work

Alex Miller (Clojure team)21:11:22

new stuff in 1.11 will not have changed this

Alex Miller (Clojure team)21:11:11

there were some interesting perf things explored in the process but I'm not sure any of that made it to the end