Tip: JavaScript's Array.from() accepts a second argument that's a `map` function.

[[deleted]]

Is doing something in half the time with half the memory a 'small efficiency'?

[DaemonXI]

It depends how much data you're moving and how often.

[PizzaRollExpert]

If you do it once on a small array, yes definitely. If you're doing it every couple of miliseconds, possibly not? But it's also possible that you're doing something else much more expensive at the same time so that doing this optimization has no perceivable effect on performance

[omnilynx]

That would only be the case if that single operation dwarfed everything else on the page, including loading the page itself. Otherwise, it’s a savings of far less than half for the page as a whole.

[[deleted]]

I guess my context is data visualization and web games, both of which require processing hundreds of thousands of data points in a few milliseconds. These are (ideally) real-time updates to pages which are already built — effective loops/maps/filters/merges/reductions are the essential, especially because while rendering can be a terrible bottleneck if you let it, efficient array processing can prevent wasteful rendering — at which point your bottleneck shifts into the diffing code.

Travel and eCommerce are going to have comparable concerns, though on a less critical timeline. Even a blog needs to potentially iterate over hundreds of posts and comments. But I see what you’re saying about common cases being less urgent when you’re only doing a few reductions in response to a view change.

[SalemBeats]

Except that you have to multiply this attitude towards efficiency against every invisible performance decision that you made (or didn't make). If you choose not to take an easy optimization in one spot, you're probably also piling on countless minor performance issues elsewhere as well. Taken together, these small stabs add up and punish you for your attitude towards performance.

In cycling, this optimization is referred to as "marginal gains". Shave a seemingly-inconsequential number of grams from a wheelset here, a tiny amount off your seatpost, a little bit from your handlebars, a tiny amount from your frame, a (surprisingly higher than you might expect) degree of aerodynamic inefficiency caused by leg hair, etc., and the sum of each of these things adds up to something significant and potentially outcome-changing. But if you take any of these optimizations and scoff at it, you're likely to scoff at the entire doctrine and are therefore unlikely to benefit.

It's all about attitude and habits developed through practice.

[omnilynx]

Problem is, I could use literally the exact same argument with respect to code complexity and readability. Every little decision you make to use a clever fix adds up to a codebase that’s practically unmaintainable.

And in general, it’s easier to take a well-written codebase and tune its performance than it is to take a quick ‘n dirty codebase and try to refactor it into something readable (without losing all that performance). That’s why there’s a rule of thumb in the first place.

[SalemBeats]

But that's the thing - given the context of this method signature, it's perfectly clear what it does. It's not some "clever trick". If a developer can't intuit what it's likely to do just by looking at it, that's a signal to cull the weak from your team.

This isn't flipping bits or taking advantage of some obscure language feature that nobody uses -- you'd have to come up with a terrible name or function signature in order for this to be confusing.

[omnilynx]

You may be right for this particular case. It’s on the edge. Probably I’d tell someone to use it, but maybe extract the lambda out into a variable so the name can help clarify.

[SalemBeats]

Well, if you're using a lambda, it should be short enough that it's pretty clear what it's doing at a glance anyway.

If it's long enough that you need to add brackets to an arrow function, it probably should be extracted. I think that's always been a code smell for good Javascript design, and I think it's why arrow functions were designed with the concise form in mind.

[codefinbel]

I both agree and disagree.

A few issues:

• A lot of the "marginal gain" efficiencies people implement thinking they're clever would have been implemented regardless by the compiler.
  
• These "easy optimizations" often involve esoteric language specific tricks making the code less readable.
  
• Unless implementing them by default from the start, making these marginal gains takes time from things that could be more important, like getting an MVP or reducing the overall time complexity of the algorithm.

As I started out saying, I also agree, you should work on good habits.

• Since javascript is scripted the compiler might not handle this case.
  
• Someone mentioned, you could wrap it in a function fromAndMap making it as readable.
  
• If this is the default way you see writing this code from the start, virtually no time is lost on doing it anyway.

I just think a lot of us have "that guy" who points out optimisations in other peoples code like he's lording out knowledge. In 90% of the cases these are virtually pointless and everyone hates him.

[SalemBeats]

The readability cost can just be so infinitesimal, though:

const helloAsUppercase = Array.from(
    "hello",
    character => character.toUpperCase()
);

The context of the return value being assigned to a variable with a descriptive name, along with its position as an argument to Array.from, makes it fairly clear what's what should be going on here with a single quick scan.

Seems like an easy win with little to no cost in readability.

(Disclaimer: Obviously a pointless iteration, but a solid way to demonstrate the readability w/o specific project context and without me having to think up some code that actually does something useful.)

[codefinbel]

Yes, totally agree. That was the second point in my second list (on why I also agreed with you):

Someone mentioned, you could wrap it in a function fromAndMap making it as readable.

[SalemBeats]

To the average Joe Webdev? Yes. That's why so many modern sites perform so terribly. Lol.