[bind10-dev] numeric/integer size on CC channel

[fujiwara at jprs.co.jp]

> From: "Michal 'vorner' Vaner" <michal.vaner at nic.cz>
>>   2. Is there performance problem to use int64_t ?
> 
> Well, on 32bit machine 64bit numbers are slower (while on 64bit they should be
> the same speed). They are twice as large, which may play role when storing many
> of them (both for memory consumption and speed, because the data will be slower
> to load and may not fit as many of them to cache).
> 
> But, compared with our use of virtual methods, several layers of ASIO, network
> communication, etc, I think the use of 64bit integers is negligible overhead and
> we don't have to worry. Especially if used in the JSON formatting ‒ that one has
> much more overhead itself.

C++ JSON output code is used at commands output or statistics output
on current codes.

>> Proposal
>> 
>>   1. Change type of intElement as int64_t
> 
> I'd be careful here. Someone should check nothing breaks because of that (eg.
> look through the cases where it is used and check it doesn't break). But
> generally, I agree.

Existing code store return value of intValue() into variables which
have suitable size. Larger value may be masked or may cause exceptions.

>>   2. Add uint64Element which holds uint64_t value.
> 
> Is there a reason to have int64_t one as well as uint64_t one? I'd like to see a
> motivation before adding more data types to that.

Statistics value is unsigned.
If we choose 32bit intElement, we cannot carry 32bit unsigned value.
If we choose 64bit intElement, we cannot carry 64bit unsigned value.

We must prepare unsigned Element.

# Except we choose 64bit intElement and 32bit unsigned statistics counters.

>>   3. Prepare automatic type conversion among intElement, uint64Element and
>>      doubleElement.
>>      If converted type cannot carry the value, exceptions will occur.
> 
> Again, with automatic conversion, we are stepping on thin ice. I'm not saying we
> definitely don't want it, but I'd like to see the motivation/use case for that.

Existing JSON to number code does not know/use type information.
You can see it in src/lib/cc/data.cc::fromStringstreamNumber().

If a string does not have a period, it is integer.
If the value exceeds integer range, it causes JSONError.
If a string have a period, it is double.

If we add uint64Element, we cannot distinguish positive integer value
and unsigned integer value.

Evaluating doubleElement in integer context is useful.
  intValue("1.1") == 1

Regards,

--
Kazunori Fujiwara, JPRS <fujiwara at jprs.co.jp>