On Tue, Jan 15, 2019 at 1:09 PM Nicolas Grekas <nicolas.grekas+...@gmail.com> wrote:
> About using "int" as return type for getId(): > > > * Can the `getId()` return type be restricted to either `int` or >> > `string`? Why is it a union type right now? Technical limitation? >> >> To allow changes in the future. The real return value here is an int, but >> the size increase due to hashing makes it a string. If we find a way to >> avoid that (or decided that we don't care about leaking addresses), we >> could change this to a (faster) int-based API. >> > > spl_object_hash() uses a XOR to hide internal addresses - so they're > already "leaking". > we also added spl_object_id() which proved much better in term of memory > usage - not only CPU. > > Mixing both arguments/approaches, what about returning a XORed int? Are we > OK with that? It'd be a welcome storage/CPU optimization from my pov. > A XORed int is not much better than returning the address directly -- it will scramble the base address, but for example not the offsets between the references (if the XOR key is the same). If people think that this is good enough for us, then of course it's better to go with the int for performance reasons. I've picked the sha1 here to be conservative. How performance critical is this API? Nikita
