[HN Gopher] Donkey: A Highly-Performant HTTP Stack for Clojure
___________________________________________________________________
Donkey: A Highly-Performant HTTP Stack for Clojure
Author : invisiblerobot
Score : 118 points
Date : 2021-02-02 21:19 UTC (1 days ago)
(HTM) web link (www.infoq.com)
(TXT) w3m dump (www.infoq.com)
| ARandomerDude wrote:
| https://github.com/AppsFlyer/donkey
| fulafel wrote:
| I wonder if they meant to write these "key takeaways" in context
| of performance, or generally? Taken on their own they don't sound
| too familiar vs why people usually decide to go with Clojure or
| not.
|
| * "Clojure frees developers from the perils of writing concurrent
| programs, but at a price."
|
| * "When concurrency is not a factor, consider using Java."
| dgb23 wrote:
| From the first statement, the "price" refers to performance
| implications. So the second refers to that too and the article
| mostly talks about performance.
|
| Pure FP generally scales well with caching/memoization, because
| functions are pure, and with concurrency, because data is
| immutable. However the paradigm typically allocates more
| garbage and often creates more indirection due to its
| declarative nature (think function
| composition/pipelines/laziness and so on). So it is not as
| suitable for fine-grained/low level optimizations as imperative
| programming.
| throwaway202199 wrote:
| > When concurrency is not a factor, consider using Java.
|
| FUD.
| brabel wrote:
| > In our benchmarks, the Clojure version underperformed by about
| 9-13% when comparing peak throughput.
|
| The performance difference between Clojure and the pure Java
| implementations was much smaller than I'd thought. Quite amazing
| for a dynamically typed language to get so close to Java in
| performance, to be honest.
|
| The ring-clojure performance was much lower than the Java
| equivalent, but that's expected because de-serialization can be A
| LOT faster when you use static types for guiding parsing (e.g.
| cache the string keys and never allocate object keys, maybe small
| values that are common as well). I wonder if Clojure contracts
| could be used for the same tricks.
| vemv wrote:
| Could you expand on the last paragraph? I have trouble
| following it
| cle wrote:
| When using a "mapper", the user tells the library up-front
| what objects will be used for holding the JSON data. You can
| do all kinds of optimizations if you know the shape of the
| data and what objects will need to be allocated in order to
| hold it, before the JSON actually arrives.
| Scarbutt wrote:
| _The performance difference between Clojure and the pure Java
| implementations was much smaller than I 'd thought. Quite
| amazing for a dynamically typed language to get so close to
| Java in performance, to be honest._
|
| That's not surprising given that they rewrote all the
| middleware in Java and the Clojure part was just a very thin
| wrapper around vertx. And that's fine, it's what makes Clojure
| usable in production, but the vast majority of Clojure users
| bash Java all the time, take this libraries for granted and
| ignore the fact that a big range of software for the JVM is
| better written in Java than in Clojure.
| nojito wrote:
| Because they literally re-wrote the majority of it to use
| vert-x directly.
|
| The clojure pieces are nothing more than a wrapper which is
| exactly what clojure is best used for.
| nickbauman wrote:
| In my testing I couldn't tell the difference between Java and
| Clojure performance solving the same problem. Probably because
| Clojure is lazy in many cases (or the implementer can choose a
| lazy implementation) where Java has to be eager all the time.
| lbj wrote:
| Amazing job guys, cant wait to test this out in the field.
___________________________________________________________________
(page generated 2021-02-03 23:02 UTC)