5 ms·

Yes, a regular for loop is a bit faster at iterating over a large list of elements than foreach in Javascript, but why on earth would you care about that kind o

Yes, a regular for loop is a bit faster at iterating over a large list of elements than foreach in Javascript, but why on earth would you care about that kind of optimization minutia in a coding interview? The question you're asking involves 10k * 3 * 30 = 900,000 data points. If a candidate wants to simply loop over all of them multiple times a second, I'd say that's a much bigger problem.

leeoniya 4y ago
> If a candidate want to simply loop over all of them multiple times a second, I'd say that's a much bigger problem. unless the task is to animate them in a rAF loop (which runs at ~60Hz), right? the task matters. in some cases the question is stupid & irrelevant, and in the other case it means getting the job done, or not. the difference between the brain-dead way and the fast way is literally 30x (53ms vs 1.8ms on my machine): https://jsfiddle.net/3ho6f5k1/ https://jsfiddle.net/3ho6f5k1/
- drewrv 4y ago
  It’s unrealistic to expect this level of optimization in a generalist whiteboard session. For a specialist, maybe. I’m not specialized in this area. For an array of 5-10 items the performance hit of foreach is worth it for readability. Maybe an interesting discussion could occur about when to sacrifice readability for performance but you won’t get that by grilling people about minutiae.
  - leeoniya 4y ago
    > For an array of 5-10 items the performance hit of foreach is worth it for readability 100% agree. my point is more about OP's example being used to prove that dumb questions get asked. if it's being asked by a good interviewer, it's usually relevant.
  - zepolen 4y ago
    > For an array of 5-10 items the performance hit of foreach is worth it for readability As always it depends, maybe that component is being called 500 times on the page making it actually 5,000 invocations. I'd FULLY expect a candidate to understand the difference and would ask in a whiteboard session. There is a lot of bloated slow javascript libraries out there and they almost always stem from the fact that most devs don't realize how much overhead function calls introduce. For the interview, there is no discussion necessary, the correct answer is simply: "I used a foreach for readability, because performance doesn't matter in this case because X." or "I used a for because performance matters in this case because Y" End of story.
    - aulin 4y ago
      one could argue that it's a job for the compiler to make sure two equivalent language constructs (map and for loop) perform similarly...
    - barrkel 4y ago
      Foreach with functions being passed being slower is an implementation detail. You don't see it in Rust, where the block body is inlined like a generic, and it's perfectly feasible for a dynamic runtime to specialize the pattern and inline based on it being a common practice, never mind polymorphic inline caches which in principle permit inlining in this case.
- aulin 4y ago
  Not sure it proves anything in interview context though. It's a language specific trivia you'll quickly learn either from experience or from a good mentor. Proves nothing about your ability to code or to be a successful member in the team. Unless you're actively looking for a candidate that knows all those JS optimization tricks.
  - Gwypaas 4y ago
    Take Rust. For each and map generally are faster because they often allow bound checks to be elided. 100% trivia.
- barrkel 4y ago
  Constant factors don't normally matter in an interview algorithm context. Focus on them often results in ugly code and can be a distraction against bigger improvements.
bluepizza 4y ago
I would care about the reading optimization. So if someone tells me "I chose a forEach instead of a for because it provides almost the same performance, but is more readable, and my code does not need the index", that's a very good sign of someone making conscious choices.

leeoniya 4y ago

> If a candidate want to simply loop over all of them multiple times a second, I'd say that's a much bigger problem. unless the task is to animate them in a rAF loop (which runs at ~60Hz), right? the task matters. in some cases the question is stupid & irrelevant, and in the other case it means getting the job done, or not. the difference between the brain-dead way and the fast way is literally 30x (53ms vs 1.8ms on my machine): https://jsfiddle.net/3ho6f5k1/ https://jsfiddle.net/3ho6f5k1/

drewrv 4y ago
It’s unrealistic to expect this level of optimization in a generalist whiteboard session. For a specialist, maybe. I’m not specialized in this area. For an array of 5-10 items the performance hit of foreach is worth it for readability. Maybe an interesting discussion could occur about when to sacrifice readability for performance but you won’t get that by grilling people about minutiae.
- leeoniya 4y ago
  > For an array of 5-10 items the performance hit of foreach is worth it for readability 100% agree. my point is more about OP's example being used to prove that dumb questions get asked. if it's being asked by a good interviewer, it's usually relevant.
- zepolen 4y ago
  > For an array of 5-10 items the performance hit of foreach is worth it for readability As always it depends, maybe that component is being called 500 times on the page making it actually 5,000 invocations. I'd FULLY expect a candidate to understand the difference and would ask in a whiteboard session. There is a lot of bloated slow javascript libraries out there and they almost always stem from the fact that most devs don't realize how much overhead function calls introduce. For the interview, there is no discussion necessary, the correct answer is simply: "I used a foreach for readability, because performance doesn't matter in this case because X." or "I used a for because performance matters in this case because Y" End of story.
  - aulin 4y ago
    one could argue that it's a job for the compiler to make sure two equivalent language constructs (map and for loop) perform similarly...
  - barrkel 4y ago
    Foreach with functions being passed being slower is an implementation detail. You don't see it in Rust, where the block body is inlined like a generic, and it's perfectly feasible for a dynamic runtime to specialize the pattern and inline based on it being a common practice, never mind polymorphic inline caches which in principle permit inlining in this case.
aulin 4y ago
Not sure it proves anything in interview context though. It's a language specific trivia you'll quickly learn either from experience or from a good mentor. Proves nothing about your ability to code or to be a successful member in the team. Unless you're actively looking for a candidate that knows all those JS optimization tricks.
- Gwypaas 4y ago
  Take Rust. For each and map generally are faster because they often allow bound checks to be elided. 100% trivia.
barrkel 4y ago
Constant factors don't normally matter in an interview algorithm context. Focus on them often results in ugly code and can be a distraction against bigger improvements.

bluepizza 4y ago

I would care about the reading optimization. So if someone tells me "I chose a forEach instead of a for because it provides almost the same performance, but is more readable, and my code does not need the index", that's a very good sign of someone making conscious choices.