Consider self-mutating methods to avoid garbage about long.js HOT 3 CLOSED

Currently, instances are meant to be immutable, which for example allows Long.js (as well as goog.math.long which it is based upon) to maintain a cache of small integer values (i.e. to reduce garbage, see). I rather think of a Long as a type replacement here, not as a library.

Also, with modern JS engines, Longs shouldn't be much of a memory problem. Each one basically is a plain object with two numbers (always explicitly cast to a 32bit int) and a bool as its properties. This is (at least I expect that) what engines have been optimized for, so optimizing this any further might make things a bit faster indeed, but might also make it a bit worse, for example if additional local variables are required.

Not exactly sure, though. A concrete test case showing the differences would be ideal.

from long.js.

Yeah, it is pretty clear that interned longs would need to be immutable and that might make more of a mess of the interface than it would help. I implemented self-mutation in ndim to get ahead of the GC losing game for front-end animation, since GC pauses plague smooth animation. It is not clear at this time whether this is a problem we will have with Long, so it would be (maybe) premature to go forth and implement this. I’ll defer the issue for now.

from long.js.

As this came up a couple of times recently, I tested out a couple of ideas in 59a3dbd but only ended up with https://github.com/dcodeIO/long.js/blob/master/src/long.js#L312

from long.js.