1 byte provides 256 values
2 bytes provide 256^2 values
...
n bytes provide 256^n values
You are asking for 10^256 possible values.
256^n = 10^256
n log 256 = 256
n = 256/log 256 ~= 107
So you would need about 107 bytes to store every id. For simplicity make that 128, nice and round. Currently, 4 bytes are used.
So for event ids, the memory usage will increase 32 fold.
The memory usage itself may not be significant, depending on the number of events
But it will require a max of 32 separate compares on 32-bit machines, compared to just 1 compare for the 4 bytes. And reading and writing to them would be much slower. Especially when considering relatively small CPU cache sizes.
Or, perhaps, you will not allocate 128 bytes, but define a number as follows: 1 integer (4 bytes) specifying length of the number in bytes, and a pointer to the byte array with the number. That would allow infinitely-sized numbers (constrained by available memory and 2 billion bytes max), but involves a dereference and makes the standard usage still 12 bytes (4 for len, 4 for pointer, 4 for actual id). And actually using the number, especially reading and writing, could be very messy.
Right now, you have 2 billion ids available. There is plenty of free space for shifting ids around, no matter how many padding ids the mods have.
