4 ms·

Ran the same test in node 0.10.33, and despite also using V8, does not have this behaviour. https://gist.github.com/dazld/2a5dc58f5c9ce61bccae https://gist.git

Ran the same test in node 0.10.33, and despite also using V8, does not have this behaviour. https://gist.github.com/dazld/2a5dc58f5c9ce61bccae https://gist.github.com/dazld/2a5dc58f5c9ce61bccae Was about to start minifying all the server code too.. ;)

mraleph 12y ago
Add 2 more characters in f3 (e.g. two empty spaces in the before return). Right now the way it's written it's still below the limit. That however does not mean you need have to minify your server code. Please don't base such decisions on some random microbenchmarks that have 0 connection to the code that you are really running in production. Instead base these decisions on profiling of your actual application. As I already said below: it is unlikely you get 70% improvement by removing all the comments in your code. For that you need an app that does nothing but a very hot tight loop calling the same small function that does almost nothing too.
- danpeddle 12y ago
  Absolutely agree - was just being a little facetious. Clearly not about to start uglifying everything running on the server just because of a random benchmark of unrepresentative functions running in a loop. Correct to point this out, especially considering the predilection of devs to micro-optimise based on the most spurious of hypotheses. Putting a single IO operation in that loop will most likely completely change the picture, anyway - although have not run the test to check.
- deleted 12y ago
  [deleted]
zallek 12y ago
As mraleph said. On node, inline limit is defined by max_inlined_source_size which is by default 600. Adding 2 characthers will reproduce the behaviour. On Chrome this limit might be different. I just used twitter to have many people testing in differents browser (and so JS engine) and so comparing behaviours :)

4 ms·

Ran the same test in node 0.10.33, and despite also using V8, does not have this behaviour. https://gist.github.com/dazld/2a5dc58f5c9ce61bccae https://gist.git

by danpeddle 12y ago

mraleph 12y ago
Add 2 more characters in f3 (e.g. two empty spaces in the before return). Right now the way it's written it's still below the limit. That however does not mean you need have to minify your server code. Please don't base such decisions on some random microbenchmarks that have 0 connection to the code that you are really running in production. Instead base these decisions on profiling of your actual application. As I already said below: it is unlikely you get 70% improvement by removing all the comments in your code. For that you need an app that does nothing but a very hot tight loop calling the same small function that does almost nothing too.
- danpeddle 12y ago
  Absolutely agree - was just being a little facetious. Clearly not about to start uglifying everything running on the server just because of a random benchmark of unrepresentative functions running in a loop. Correct to point this out, especially considering the predilection of devs to micro-optimise based on the most spurious of hypotheses. Putting a single IO operation in that loop will most likely completely change the picture, anyway - although have not run the test to check.
- deleted 12y ago
  [deleted]
zallek 12y ago
As mraleph said. On node, inline limit is defined by max_inlined_source_size which is by default 600. Adding 2 characthers will reproduce the behaviour. On Chrome this limit might be different. I just used twitter to have many people testing in differents browser (and so JS engine) and so comparing behaviours :)