6 ms·

Clojure has a slow startup time. It is not in itself slow. It's important to get these distinctions right! Some people, unfortunately, form impressions from he

by lukev 14y ago

Clojure has a slow startup time. It is not in itself slow. 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. That's much less damning overall than "Clojure is slow."

debacle 14y ago
You should have read the entire article: > How fast is Clojure at running your code once it finally has got going? ... Clojure is on average 4x slower than Java and 2x slower than Scala. That's pretty freaking slow.
- lukev 14y ago
  And about twice as fast as Erlang, 5x faster than Ruby, Python or PHP and 10x faster than Perl.[1] It's all relative. [1] http://shootout.alioth.debian.org/u64q/which-programming-languages-are-fastest.php http://shootout.alioth.debian.org/u64q/which-programming-lan...
  - exim 14y ago
    On the other hand, those languages do not have a pretension of being fast.
  - gizzlon 14y ago
    While interesting, those benchmarks are only useful if you implement something remotely similar to the actual benchmarks. Just glazing over them, they seem to be "unfairly" targeted at low-level languages. That said, they are fun to look at. I just had a wtf-moment looking at this: http://shootout.alioth.debian.org/u32/performance.php?test=nbody http://shootout.alioth.debian.org/u32/performance.php?test=n... ~20 seconds vs ~20 minutes??
    - igouy 14y ago
      1) those benchmarks are only useful if... Any benchmark is only useful if... http://shootout.alioth.debian.org/dont-jump-to-conclusions.php http://shootout.alioth.debian.org/dont-jump-to-conclusions.p... 2) "unfairly" targeted at low-level languages Don't make "unfair" accusations -- say why you think that. 3) ~20 seconds vs ~20 minutes?? Did you mean vs ~20 hours?
      - gizzlon 14y ago
        > Don't make "unfair" accusations -- say why you think that Because there seems to be a bias in selecting the problems solved in the benchmark games: to be "fair" they should be randomly selected from a pool of all possible problems solved with computer programs. Or, maybe, the frequency of these problems in the real world should be taken into account? Of course, they're not actually unfair since they hide nothing. The error is in the interpretation, e.g. "My program will be faster if I write it in language X instead of Y." The nice link you posted sums it up well: "Programming languages are compared against each other as though their designers intended them to be used for the exact same purpose - that just isn't so." edit: Spelling..
        igouy 14y ago
        1) "they're not actually unfair" So don't say that they are! 2) "The nice link you posted sums it up well" I agree - but then I wrote those words. 3) "there seems to be a bias in selecting the problems solved in the benchmark games" You still haven't said anything that suggests they are "targeted at low-level languages".
        gizzlon 14y ago
        1) I didn't .. 3) I did in GP
        igouy 14y ago
        1) You implied "unfair" by opining on what they would have to do to be "fair"; and you said something less vague than "unfair", you said "unfairly" targeted at low-level languages. If you don't mean to say they are "unfair" then your words are going to confuse ;-) 3) GP? Your opining about "selecting the problems" doesn't support the claim "targeted at low-level languages" anymore than it supports the claim targeted at high-level languages :-) As you noted the important thing to remember is that timing measurements are not promises, and they aren't general answers to the question - Will my program be faster if I write it in language X?
  - bad_user 14y ago
    Those benchmarks are fairly useless, because it doesn't compare idiomatic usage of those languages, but rather the capability of those languages to drop to low-level primitives and libraries. I did an experiment once, testing out a simple web-service on the JVM and Scala (with Scalatra) yields the same performance as Java (with Jax-RS), while Clojure (with Noir) is only 2x to 3x as slow and JRuby (Sinatra) is only 4x-5x as slow as Java.
    - igouy 14y ago
      >>Those benchmarks are fairly useless, because it doesn't compare idiomatic usage of those languages...<< You seem to be complaining that the programmers were not forced to write slow programs :-) >>I did an experiment once...<< And you used libraries.
      - bad_user 14y ago
        No, I'm complaining that those benchmarks aren't mirroring the way developers actually write code.
        igouy 14y ago
        What specifically do you think the difference is, and how do you know?
        deleted 14y ago
        [deleted]
  - lukev 14y ago
    This is the same benchmark that is used in the OP. So if you object to the characterization of Ruby/Python/PHP vs Clojure, you can make the same objection regarding the characterization of Clojure vs C.
- matthavener 14y ago
  You can always match the speed of java in critical areas by disabling number boxing, adding type hints, and using the mutable versions of data structures. This is what prismatic did for their ML computation code: http://www.infoq.com/presentations/Why-Prismatic-Goes-Faster-With-Clojure http://www.infoq.com/presentations/Why-Prismatic-Goes-Faster...
- fogus 14y ago
  > That's pretty freaking slow. I suppose in a vacuum it is indeed (assuming the measurements are general), but in my actual use the speed of Clojure has been more than sufficient. People like to view programming language speed as a black and white issue in the context of blog and HN posting, but in many uses runtime and startup speed considerations are only part of the puzzle.
bad_user 14y ago
Slow/fast is a subjective metric, however in case of a language like Clojure you have to pay the price for convenience in the form of a performance tax when compared to Java or Scala. This may be acceptable, depends on where you're coming from and what you're needs are. For instance if you are coming from Ruby or Python because you want much better performance and you think the JVM is awesome for that, then Clojure may not be a good choice. On the other hand if you want a modern Lisp that's also reasonably fast and that has access to the JVM, then Clojure is a really good choice. Personally that's why I like Scala, but you know, the best language is whatever makes you happier and more productive.
- gaius 14y ago
  Tax is the wrong word... It's not the case that the Clojure (the language, the developers, etc) benefits from slow startup. Fine is probably more accurate.
  - bad_user 14y ago
    "Performance" is never the end-goal, but rather a coin you can trade for other things, like convenience, lower latency, fewer hardware resources, getting results faster, scalability, etc... basically anything that makes you or your clients happier. When people say they want performance, they actually mean they'd like the flexibility to gain something else by paying with performance. That's why I used "tax" which I think is very suitable.
  - technomancy 14y ago
    Actually part of the reason startup is slow is that the JVM's JIT compiler doesn't optimize its compilations until it's determined that a given method is in a hotspot that would benefit from the optimization. Because it relies on runtime information, it's able to perform much better-informed optimizations than it would with a fully up-front compiler, but the price you pay is that the optimizations are deferred. So in this case tax is exactly the right word.

by lukev 14y ago

debacle 14y ago

You should have read the entire article: > How fast is Clojure at running your code once it finally has got going? ... Clojure is on average 4x slower than Java and 2x slower than Scala. That's pretty freaking slow.

lukev 14y ago
And about twice as fast as Erlang, 5x faster than Ruby, Python or PHP and 10x faster than Perl.[1] It's all relative. [1] http://shootout.alioth.debian.org/u64q/which-programming-languages-are-fastest.php http://shootout.alioth.debian.org/u64q/which-programming-lan...
- exim 14y ago
  On the other hand, those languages do not have a pretension of being fast.
- gizzlon 14y ago
  While interesting, those benchmarks are only useful if you implement something remotely similar to the actual benchmarks. Just glazing over them, they seem to be "unfairly" targeted at low-level languages. That said, they are fun to look at. I just had a wtf-moment looking at this: http://shootout.alioth.debian.org/u32/performance.php?test=nbody http://shootout.alioth.debian.org/u32/performance.php?test=n... ~20 seconds vs ~20 minutes??
  - igouy 14y ago
    1) those benchmarks are only useful if... Any benchmark is only useful if... http://shootout.alioth.debian.org/dont-jump-to-conclusions.php http://shootout.alioth.debian.org/dont-jump-to-conclusions.p... 2) "unfairly" targeted at low-level languages Don't make "unfair" accusations -- say why you think that. 3) ~20 seconds vs ~20 minutes?? Did you mean vs ~20 hours?
    - gizzlon 14y ago
      > Don't make "unfair" accusations -- say why you think that Because there seems to be a bias in selecting the problems solved in the benchmark games: to be "fair" they should be randomly selected from a pool of all possible problems solved with computer programs. Or, maybe, the frequency of these problems in the real world should be taken into account? Of course, they're not actually unfair since they hide nothing. The error is in the interpretation, e.g. "My program will be faster if I write it in language X instead of Y." The nice link you posted sums it up well: "Programming languages are compared against each other as though their designers intended them to be used for the exact same purpose - that just isn't so." edit: Spelling..
      - igouy 14y ago
        1) "they're not actually unfair" So don't say that they are! 2) "The nice link you posted sums it up well" I agree - but then I wrote those words. 3) "there seems to be a bias in selecting the problems solved in the benchmark games" You still haven't said anything that suggests they are "targeted at low-level languages".
        gizzlon 14y ago
        1) I didn't .. 3) I did in GP
        igouy 14y ago
        1) You implied "unfair" by opining on what they would have to do to be "fair"; and you said something less vague than "unfair", you said "unfairly" targeted at low-level languages. If you don't mean to say they are "unfair" then your words are going to confuse ;-) 3) GP? Your opining about "selecting the problems" doesn't support the claim "targeted at low-level languages" anymore than it supports the claim targeted at high-level languages :-) As you noted the important thing to remember is that timing measurements are not promises, and they aren't general answers to the question - Will my program be faster if I write it in language X?
- bad_user 14y ago
  Those benchmarks are fairly useless, because it doesn't compare idiomatic usage of those languages, but rather the capability of those languages to drop to low-level primitives and libraries. I did an experiment once, testing out a simple web-service on the JVM and Scala (with Scalatra) yields the same performance as Java (with Jax-RS), while Clojure (with Noir) is only 2x to 3x as slow and JRuby (Sinatra) is only 4x-5x as slow as Java.
  - igouy 14y ago
    >>Those benchmarks are fairly useless, because it doesn't compare idiomatic usage of those languages...<< You seem to be complaining that the programmers were not forced to write slow programs :-) >>I did an experiment once...<< And you used libraries.
    - bad_user 14y ago
      No, I'm complaining that those benchmarks aren't mirroring the way developers actually write code.
      - igouy 14y ago
        What specifically do you think the difference is, and how do you know?
      - deleted 14y ago
        [deleted]
- lukev 14y ago
  This is the same benchmark that is used in the OP. So if you object to the characterization of Ruby/Python/PHP vs Clojure, you can make the same objection regarding the characterization of Clojure vs C.
matthavener 14y ago
You can always match the speed of java in critical areas by disabling number boxing, adding type hints, and using the mutable versions of data structures. This is what prismatic did for their ML computation code: http://www.infoq.com/presentations/Why-Prismatic-Goes-Faster-With-Clojure http://www.infoq.com/presentations/Why-Prismatic-Goes-Faster...
fogus 14y ago
> That's pretty freaking slow. I suppose in a vacuum it is indeed (assuming the measurements are general), but in my actual use the speed of Clojure has been more than sufficient. People like to view programming language speed as a black and white issue in the context of blog and HN posting, but in many uses runtime and startup speed considerations are only part of the puzzle.

bad_user 14y ago

Slow/fast is a subjective metric, however in case of a language like Clojure you have to pay the price for convenience in the form of a performance tax when compared to Java or Scala. This may be acceptable, depends on where you're coming from and what you're needs are. For instance if you are coming from Ruby or Python because you want much better performance and you think the JVM is awesome for that, then Clojure may not be a good choice. On the other hand if you want a modern Lisp that's also reasonably fast and that has access to the JVM, then Clojure is a really good choice. Personally that's why I like Scala, but you know, the best language is whatever makes you happier and more productive.

gaius 14y ago
Tax is the wrong word... It's not the case that the Clojure (the language, the developers, etc) benefits from slow startup. Fine is probably more accurate.
- bad_user 14y ago
  "Performance" is never the end-goal, but rather a coin you can trade for other things, like convenience, lower latency, fewer hardware resources, getting results faster, scalability, etc... basically anything that makes you or your clients happier. When people say they want performance, they actually mean they'd like the flexibility to gain something else by paying with performance. That's why I used "tax" which I think is very suitable.
- technomancy 14y ago
  Actually part of the reason startup is slow is that the JVM's JIT compiler doesn't optimize its compilations until it's determined that a given method is in a hotspot that would benefit from the optimization. Because it relies on runtime information, it's able to perform much better-informed optimizations than it would with a fully up-front compiler, but the price you pay is that the optimizations are deferred. So in this case tax is exactly the right word.