20 ms·
If you're storing references to larger objects, your larger objects are what's taking up the space, which I think was the point (66% more pointers are useless i
by benwr 14y ago
If you're storing references to larger objects, your larger objects are what's taking up the space, which I think was the point (66% more pointers are useless if you can't also store 66% more of the objects they point to).
Also, I think on a 64-bit machine with common DDR SDRAM, a memory location is 64 bits wide, no matter the size of the integer contained there. Not sure about this, however.
- zanny 14y agoMost modern architectures like AMD64 use 40 bit memory references in the CPU, but write them as 64 bit to memory. That is why they have much lower addressable memory than the logical limit.
- zurn 14y agoSome compilers/runtimes support pointer compression (eg. https://wikis.oracle.com/display/HotSpotInternals/CompressedOops https://wikis.oracle.com/display/HotSpotInternals/Compressed...)
- DennisP 14y agoNot if you're storing lots of references to the same object, which is what I'm often doing. And my objects are really small anyway.
- alecbenzer 14y ago> If you're storing references to larger objects, your larger objects are what's taking up the space, which I think was the point (66% more pointers are useless if you can't also store 66% more of the objects they point to). Right, of course... > I really don't know all that much about architecture (yet), so that's totally possible, and I might be wrong about the 66% thing I guess. edit: Actually, about the whole more objects thing, there might be some strange use case where you only have a few objects but are storing multiple references to them in a list. But yeah, in general, the benefit goes down with larger objects.