0

Does it matter how big numbers to calculate in JavaScript Engine, especially V8 in NodeJS?

The applicable example: I'm calculating in loops time date variables in milliseconds and have some time variables in minutes. I have doubts should I convert all times from minutes to milliseconds to have everything consistent, or vice-versa to have smaller values for easer calculation?

  • time in minutes: 27686190
  • time in milliseconds: 1661171400000

Converting complexity from milliseconds to minutes (I believe insignificant) - 2 variables per loop. From minutes to milliseconds - 2 variables once.

kosiakMD
  • 923
  • 7
  • 22
  • 2
    nodejs would either use 32bit or 64bit integers internally and the cpu which in most case would be 64bit based, so the size wont matter – Dean Van Greunen Aug 22 '22 at 11:09
  • 2
    See [*What is JavaScript's highest integer value that a number can go to without losing precision?*](https://stackoverflow.com/questions/307179/what-is-javascripts-highest-integer-value-that-a-number-can-go-to-without-losin) `Number.MAX_SAFE_INTEGER / 1000 / 60` gives about 150,119,987,579 minutes (about 285,000 years). – RobG Aug 22 '22 at 11:13
  • 1
    What do you mean by complexity here?. If your source is milliseconds, then keep it that way, your adding more complexity code wise otherwise, and that would be way slower than any big/small number calculation difference if any.. – Keith Aug 22 '22 at 11:27
  • 1
    CPUs are incredibly fast at math operations, so unless your number is so big as to require using [BigInt](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt#description) (which it isn't), this isn't a major concern. A bigger concern is the overhead of performing loops to convert the numbers. If you want to increase performance and have many iterations, I'd be focusing on the type of loop, the amount of work done within each iteration, etc. – Richard Dunn Aug 22 '22 at 11:28
  • 1
    @DeanVanGreunen Node.js cannot use 64-bit integers internally, that would violate the JS spec because results would be _too precise_. – jmrk Aug 22 '22 at 18:41
  • @jmrk As of v10.4.0 NodeJS supports the BigInt type natively (see MDN BigInt docs). These support arithmetic operations too. – Dean Van Greunen Aug 23 '22 at 06:09
  • @jmrk [read this](https://stackoverflow.com/a/24037917/6651840) – Dean Van Greunen Aug 23 '22 at 06:10
  • 1
    @DeanVanGreunen BigInts are an entirely different story, they have neither constant size nor constant cost of operations. For Numbers (as in this question), "Nodejs would use [...] 64bit integers internally" is just incorrect. – jmrk Aug 23 '22 at 08:21
  • @jmrk all JS math is done on 64-bit floating point numbers1 – Dean Van Greunen Aug 23 '22 at 10:33

1 Answers1

2

Apart from BigInt, all JS math is done on 64-bit floating point numbers1. All operations have constant time complexity, they do not depend on the values they are working with.

Either way, start by writing clear, idiomatic and correct code. It will be optimised well enough by the engine. Only when you identify a performance bottleneck in a particular part of the code, and think you can outsmart the engine optimisations, benchmark your different approaches.

1: Some engines, V8 in particular, optimise storage and computation for small integers (like most array indices). Operations on them might be faster than a floating-point operation, but still they have constant time complexity and do not depend on which integers they work with.

Bergi
  • 630,263
  • 148
  • 957
  • 1,375