6 ms·

devongovett/jensnockert: what was your experience with using CoffeeScript for such low level code? Did you need to consciously avoid certain CoffeeScript featur

devongovett/jensnockert: what was your experience with using CoffeeScript for such low level code? Did you need to consciously avoid certain CoffeeScript features that could negatively impact performance?

jensnockert 15y ago
Mostly avoided the regular for loops, replacing them with `for ... by 1`, to make sure the compiler knows in which direction to iterate. Otherwise it is pretty similar to javascript, most coffeescript constructs map pretty simply down to javascript, so optimization tips for one language mostly applies to the other.
devongovett 15y ago
Overall positive, but as with any programming language, you have to be careful sometimes. For example, the for loop in CoffeeScript can be slow if you aren't careful: for i in [0...10] doSomething() is slower than for i in [0...10] by 1 doSomething() because of the way it is compiled, so we always include the `by 1` as an optimization. Another one is that if you have a function and the last thing in that function is a loop of some kind, CoffeeScript will try to return an array from that function collecting the results of the loop. So we explicitly put a return statement at the end of the function to avoid this and the performance penalties. There are probably a few more to be careful of, but overall performance characteristics are similar to JS. I'm sure Jens has some thoughts too, but overall I think it was a positive experience.
- jbanon 15y ago
  This is the difference in compiled output for those examples: var i; for (i = 0; i < 10; i++) { doSomething(); } for (i = 0; i < 10; i += 1) { doSomething(); } http://jashkenas.github.com/coffee-script/#try:for%20i%20in%20%5B0...10%5D%0A%20%20doSomething()%0A%0Afor%20i%20in%20%5B0...10%5D%20by%201%0A%20%20doSomething() http://jashkenas.github.com/coffee-script/#try:for%20i%20in%...
  - devongovett 15y ago
    Oops, I should have written it using a variable instead... i.e. for i in [0...test] doSomething() for i in [0...test] by 1 doSomething() compiles to: var i; for (i = 0; 0 <= test ? i < test : i > test; 0 <= test ? i++ : i--) { doSomething(); } for (i = 0; i < test; i += 1) { doSomething(); } the latter one being much faster because it isn't testing the direction the counter should be going all the time.
    - jashkenas 15y ago
      This is one of the grayer areas. After your experience writing this decoder ... would you prefer CoffeeScript to keep its loops that can go in either direction, or would you prefer loops to always iterate upwards, and have to be explicit if you'd like to count from "[100..1] by -1" ?
      - devongovett 15y ago
        Hmmm, well I think it's better if they can go in any direction by default otherwise people will be confused. The `by 1` should be considered an optimization IMO.
      - nitrogen 15y ago
        What if you compiled it something like this: for i in [a...b] becomes if(a <= b) { for(i = a; i < b; i++) { // Code } } else { for(i = a; i > b; i--) { // Code again } } Or otherwise moved the extra conditions outside the loop so they only get computed once?
        jashkenas 15y ago
        Unfortunately, that requires repeating the entire body of the loop, and so isn't workable/acceptable for our purposes. If you'd like to see the original conversation that led to the current compilation, it's all available on the GitHub issues.

jensnockert 15y ago

Mostly avoided the regular for loops, replacing them with `for ... by 1`, to make sure the compiler knows in which direction to iterate. Otherwise it is pretty similar to javascript, most coffeescript constructs map pretty simply down to javascript, so optimization tips for one language mostly applies to the other.

devongovett 15y ago

Overall positive, but as with any programming language, you have to be careful sometimes. For example, the for loop in CoffeeScript can be slow if you aren't careful: for i in [0...10] doSomething() is slower than for i in [0...10] by 1 doSomething() because of the way it is compiled, so we always include the `by 1` as an optimization. Another one is that if you have a function and the last thing in that function is a loop of some kind, CoffeeScript will try to return an array from that function collecting the results of the loop. So we explicitly put a return statement at the end of the function to avoid this and the performance penalties. There are probably a few more to be careful of, but overall performance characteristics are similar to JS. I'm sure Jens has some thoughts too, but overall I think it was a positive experience.

jbanon 15y ago
This is the difference in compiled output for those examples: var i; for (i = 0; i < 10; i++) { doSomething(); } for (i = 0; i < 10; i += 1) { doSomething(); } http://jashkenas.github.com/coffee-script/#try:for%20i%20in%20%5B0...10%5D%0A%20%20doSomething()%0A%0Afor%20i%20in%20%5B0...10%5D%20by%201%0A%20%20doSomething() http://jashkenas.github.com/coffee-script/#try:for%20i%20in%...
- devongovett 15y ago
  Oops, I should have written it using a variable instead... i.e. for i in [0...test] doSomething() for i in [0...test] by 1 doSomething() compiles to: var i; for (i = 0; 0 <= test ? i < test : i > test; 0 <= test ? i++ : i--) { doSomething(); } for (i = 0; i < test; i += 1) { doSomething(); } the latter one being much faster because it isn't testing the direction the counter should be going all the time.
  - jashkenas 15y ago
    This is one of the grayer areas. After your experience writing this decoder ... would you prefer CoffeeScript to keep its loops that can go in either direction, or would you prefer loops to always iterate upwards, and have to be explicit if you'd like to count from "[100..1] by -1" ?
    - devongovett 15y ago
      Hmmm, well I think it's better if they can go in any direction by default otherwise people will be confused. The `by 1` should be considered an optimization IMO.
    - nitrogen 15y ago
      What if you compiled it something like this: for i in [a...b] becomes if(a <= b) { for(i = a; i < b; i++) { // Code } } else { for(i = a; i > b; i--) { // Code again } } Or otherwise moved the extra conditions outside the loop so they only get computed once?
      - jashkenas 15y ago
        Unfortunately, that requires repeating the entire body of the loop, and so isn't workable/acceptable for our purposes. If you'd like to see the original conversation that led to the current compilation, it's all available on the GitHub issues.