@itsjamie hiw does this reduce cpu load? When you say it delays evaluation what does it mean? It seems like this is just passing call site one place down but it is not lazily evaluated in next io loop as far as I can understand.
Also creating a bounded method for a log will inherently add closure so is this really saving up on heap memory?
Would love to get more understanding why this is making things better on low end devices.

hiw does this reduce cpu load? When you say it delays evaluation what does it mean?

This saves CPU load because we don't need to actually calculate the log message if the verbosity level would mean it would never be printed to the console.

By directly calling the function normally, and passing the string into the log message call, we need to generate that string every invocation rather than when it is actually needed to be printed.

is this really saving up on heap memory?

So, I think on memory usage we only come out positive because the strings are relatively large. Correct that an even better implementation would be a singular bound function rather than an inline definition at each log call, because then we would pay for a single function definition.

Thanks @itsjamie, this makes sense.
Why not create a build then that totally removes logger lines? Arguing debugability vs performance, I would say that adding a Babel transform to remove all logs would probably be better than plucking specific log lines for production builds.

Absolutely, removing logs from the actual build makes a lot of sense. But given it was a large impact, and an easy fix in this one particular case, I felt it was a decent contribution that could help everyone that is using the built distributable directly :)