> On 30 May 2016, at 5:49 , Henrik Johansen <henrik.s.johan...@veloxit.no> > wrote: > > A few more comments below; I'm not seeing the things you describe when > testing in my image... > >>> >>> | id | >>> id := LargePositiveInteger. >>> 1 to: (16777215 + 50) do: [:each | >>> id := id digitAdd: 1]. >>> id. >>> >>> Given the comment it should overflow and the value be 50? This is not what >>> the result is. So shall the truncation be added again or at least the >>> comment be updated? The code will go from LargePositiveInteger to >>> SmallInteger when overflowing from three to four bytes > > On which VM does it overflow to SmallInteger? I've never seen this, on the > one I tested the expression in last mail, the "overflowing" digitAdd: > returned a 4-byte LargePositiveInteger.
It's starting to come back to me; IIRC, + will normalize results to SmallIntegers, digitAdd: will not. I thought it would be nice to use a single replaceFrom:to:with:startingAt: call to insert the entire counter; however, I didn't bench that particular part. So while the rewrite overall gained a small amount of speed, it turns out digitAdd: is quite slow (even though it's a primitive), so reverting to using Smallinteger arithmetic for the counter, and inserting the counter a digit at a time is most likely worth it: "Pharo4, LargeInteger counter" [OID new] bench '1,194,004 per second' "Pharo4, reverted to SmallInteger counter" [OID new] bench '1,681,203 per second' The relevant changes should be present in attachment. Cheers, Henry
OIDrevertCounter.cs
Description: Binary data
signature.asc
Description: Message signed with OpenPGP using GPGMail
