Vladimir Panteleev wrote:
I just realized that by "performance" you might have meant memory leaks.
No, in this context I meant improving performance by not scanning the void[] memory for pointers.
Well, sure, if you can say that my programs crashing every few hours due to running out of memory is a "performance" problem. I'm sorry to sound bitter, but this was the cause of much annoyance for my software's users. It took me to write a memory debugger to understand that no matter how much you chase void[]s with hasNoPointers, there will always be that one ~ which you overlooked.
I'm curious what form of data you have that always seem to look like valid pointers. There are a couple other options you can pursue - moving the gc pool to another location in the address space, or changing the alignment of your void[] data so it won't look like aligned pointers (the gc won't look for misaligned pointers).
Or just use ubyte[] instead.
As much as I try to look from an objective perspective, I don't see how a memory leak (and memory leaks in D usually mean that NO memory is being freed, except for small lucky objects not having bogus pointers to them) is a problem less significant than an obscure case that involves allocating a void[], storing a pointer in it and losing all other references to the object.
Because one is an obvious failure, and the other will be memory corruption. Memory corruption is pernicious and awful.
In fact, I just searched the D documentation and I couldn't find a statement saying whether void[] are scanned by the GC or not. Enter mr. D-newbie, who wants to write his own network/compression/file-copying/etc. library/program and stumbles upon void[], the seemingly perfect abstract-binary-data-container type for the job... (which is exactly what happened with yours truly). P.S. Not trying to push my point of view, but just trying to offer some perspective from someone who has been bit by this design choice...
Hmm. Wouldn't compression data be naturally a ubyte[] type?
