TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Why is Clojure so slow?

80 点作者 Mitt将近 13 年前

14 条评论

lukev将近 13 年前
Clojure has a slow <i>startup time</i>. It is not in itself slow.<p>It's important to get these distinctions right! Some people, unfortunately, form impressions from headlines and in this case it's extremely inaccurate. If you read the article you'll get the truth - there are startup time problems causing issues with using Clojure for command-line programs.<p>That's much less damning overall than "Clojure is slow."
评论 #4223439 未加载
评论 #4223683 未加载
wanderingmarker将近 13 年前
To Clojure-curious people: please ignore this article. It is misinformed.<p>Others on this thread have pointed out that the Alioth benchmark takes startup time into account. Yes, this imposes a startup penalty on Clojure.<p>More importantly, the implementations of each individual benchmark vary significantly in performance quality. High-performance Clojure requires a couple of tricks in type hinting, using unchecked arithmetic, and preferring native Java arrays.<p>I looked at a couple of the benchmarks, and the mandelbrot example uses those tricks. Notice the performance there: <a href="http://shootout.alioth.debian.org/u64/performance.php?test=mandelbrot" rel="nofollow">http://shootout.alioth.debian.org/u64/performance.php?test=m...</a><p>Notice that Java 7 and gcc run at about the same speed, and Clojure is only about 2.2x slower (than C). Scala is about 1.9x slower (than C). gcc is about 1.5x slower than Intel Fortran.<p>To make the benchmark more fair: (1) all timings should disregard startup time; and (2) all JVM languages should have the opportunity to run the benchmark a few thousand times before timing it. Otherwise, it measures JVM startup time, and then it measures how long it takes the JIT to achieve maximum optimization. By comparison, the C and Fortran code runs at full speed almost out of the gate.<p>All-in-all, considering that Clojure is an extremely high-level language I consider its performance impressive [1]. Yes, the inner loops need to be coded in a slightly un-idiomatic manner, but you can do all this in the comfort of your REPL, which makes the process of making optimizations reasonably painless.<p>[1] Don't forget to scroll down the mandelbrot results and look at the stellar performance of other popular high-level languages.
评论 #4225296 未加载
yason将近 13 年前
Don't compare Clojure to C, comparing it to Python or Ruby makes more sense because they're all high-level dynamic languages. Sure Clojure runs on the compiling JVM but that doesn't put it into another category; you can also JIT compile Python in a few ways.<p>If we can make working websites and even games in Python, we can make them in Clojure too. What kills Clojure for small scripts and not-long-running applications is the startup time and that can mostly be attributed to JVM. Also, the memory footprint of a JVM process tends to grow a lot over time.<p>I see Clojure rising above specific platforms, though. JVM is in a slow death spiral. CLR might have some traction on Windows. If Python got it platform resettled on something more sophisticated than CPython, that might be a good ecosystem for Clojure.
评论 #4223822 未加载
评论 #4223383 未加载
评论 #4223095 未加载
rbanffy将近 13 年前
How slow is slow?<p>If it takes me 3 months to deliver a given program in Clojure and 6 to deliver its Java equivalent, the Clojure one already has 3 months of lead. Assuming the Java one is twice as fast, it'll take 45 days to catch up.<p>Development time is expensive, computers are cheap and get twice as fast every year or so.<p>While a long startup time is annoying, it can certainly be optimized out if someone focuses enough attention to the low level aspects of the runtime.
评论 #4223179 未加载
评论 #4223995 未加载
评论 #4223388 未加载
kibwen将近 13 年前
<i>"When using the ClojureScript compiler on a hello word example with advanced optimisation, we end up with some 100kb of Javascript. [...] The Google Closure compiler certainly helps here by removing lots of unused code, and the resulting Javascript file is indeed free from all docstrings etc."</i><p>So does the ClojureScript compiler basically just embed a Clojure interpreter in every file? I'd be interested to see the code prior to optimization.
评论 #4223542 未加载
m_for_monkey将近 13 年前
Hello World execution time benchmark with other languages:<p><a href="http://lists.nongnu.org/archive/html/chicken-users/2011-03/msg00070.html" rel="nofollow">http://lists.nongnu.org/archive/html/chicken-users/2011-03/m...</a><p><a href="http://lists.nongnu.org/archive/html/chicken-users/2011-03/msg00090.html" rel="nofollow">http://lists.nongnu.org/archive/html/chicken-users/2011-03/m...</a><p><a href="http://news.ycombinator.com/item?id=2698579" rel="nofollow">http://news.ycombinator.com/item?id=2698579</a>
martintrojer将近 13 年前
Have a look at Rich Hickey's keynote presentation from Conj2011; <a href="http://blip.tv/clojure/rich-hickey-keynote-5970064" rel="nofollow">http://blip.tv/clojure/rich-hickey-keynote-5970064</a><p>He pretty much starts off by talking about making Clojure "leaner", faster at starting up etc.<p>He mentions stuff like a "production" jar with less metadata, hoisted evaluator and even some kind of tree shaking ala ProGuard.
ivanb将近 13 年前
If Clojure could dump the Lisp image like SBCL's save-lisp-and-die function, the startup time would be greatly reduced. I wonder if JVM itself can dump its current state and then restore execution.<p>Another approach to the problem would be similar to FastCGI: keep one Clojure server process running and execute scripts on it.
评论 #4223006 未加载
评论 #4222996 未加载
评论 #4223024 未加载
bitcracker将近 13 年前
It's an implementation problem of Java.<p>I never understood why the JVM folks didn't get along to develop a JIT cache. That means the first time I start a Java program it would run normally slow. But from the second run on it would use the native cache and run immediately fast with native performance. That would eliminate many performance problems of Java.<p>I know that there already is a solution which uses a Java server to serve the application as client which reduces the startup time but this is not very convenient to use.<p>The slowness of Clojure is a typical problem of all languages which are based on JVM. Racket Scheme, for instance, which is a Lisp like language but NOT based on JVM, needs just 0.062s to print "Hello World" (compiled) on my system.
评论 #4224502 未加载
评论 #4224365 未加载
评论 #4223761 未加载
fshen将近 13 年前
Clojure startup time is slow. AOT helps a little. <a href="http://clojure.org/compilation" rel="nofollow">http://clojure.org/compilation</a><p>Clojure runs quite fast, in my experience. I have written an web app <a href="http://rssminer.net" rel="nofollow">http://rssminer.net</a>, in Clojure (and some Java). On a small VPS(512M RAM, 1 core CPU), It can handle about 300 request per second, On my desktop, about 2000 req/s. Which is not slow, at least.<p>The persistent data structures Clojure use is fast too. I did some test a long ago, It's roughly the same speed as Java collections.
djhworld将近 13 年前
I remember seeing somewhere that someone looked into tackling the problem of the startup time by stripping the clojure core libs of unessential metadata like docstrings etc<p>I'm not sure if they went through with it though
评论 #4234522 未加载
Chrix将近 13 年前
The Clojure's start-up is slow because the source files are compiled. But once your program is launched, its perfs are correct and very close to Java. About the immutable data structure, don't forget each method doesn't return a copy of the data. It's more clever using changes detection.<p>You can read a lot of information about this part of Clojure in the book "Practical Clojure". I'm reading it and I'm learning some stuffs about Clojure.<p>To conclude, Clojure is fine for "long" program running.
评论 #4224260 未加载
Mitt将近 13 年前
What I would like to see is a `defconstant` macro, which introduces a constant that can not be changed anymore without restarting the JVM.<p>(def x 1) ; x = 1 (def x 2) ; x = 2 now<p>(defconstant y 1) ; y = 1 (defconstant y 2) ; Exception<p>Also a way of fixing functions would be good, so that no lookup is required. Calling such a fixed function has no overhead, it would be a direct call.
评论 #4223437 未加载
评论 #4223098 未加载
评论 #4223093 未加载
EternalFury将近 13 年前
I don't know if I should laugh or cry. Let's just say rock stars are not engineers.