4 ms·
Honestly? Most of the time you can use an approximation. At worst you allocate a single extra byte unless your integers are hundreds of bits long (I worked this
by o11c 2y ago
Honestly? Most of the time you can use an approximation. At worst you allocate a single extra byte unless your integers are hundreds of bits long (I worked this out once but I forget where I left the details). Just multiply by the ratio of logs or something like that.
- Nevermark 2y agoNice. The best kind of optimization: Go lazy, to go fast. I often go slow, to go fast. But lazy is the supremum.
- eapriv 2y agoIsn’t “the ratio of logs” going to be slower?
- o11c 2y agoI mean the constant logs of the bases; you get to hard-code this in the algorithm. One interesting coincidence is that log₁₀(2) ~= log₂(10) - 3, thus the 83 ~= 78 below. If you use an 8-bit shift, depending on which direction you're going, you multiply the input length by 851 (which is 3*256 + 83) or 78, then shift by 8. This starts being wasteful at 23 bits, but is pretty cheap on 8-bit CPUs. For a more accurate approximation (slackening at 289 bits), 217706 (3<<16 + 21098) or 19729, then >> 16
- exyi 2y agoI'd assume that the serializer is writing directly into the output buffer, so you'd have to shift everything left by one character if you overallocate. With the added checks for this, it might be faster to compute it precisely the first time.