On Nov 14, 2007 10:25 AM, steve uurtamo <[EMAIL PROTECTED]> wrote: > > And it's not fast either. Free() has a reputation of being > > slow, and that's not surprising if you look at the way it is > > almost always implemented: scanning a list of addresses in > > order to amalgamate the newly freed memory with adjacent free > > areas. > > this is a burden for the OS, not a defect in the language. as far > as the executing code is concerned, it's just releasing responsibility > for the block attached to the pointer. the OS can merrily insertion > sort it for all i care, but that's being handled elsewhere and isn't a > function of the language. heck, the kernel could tell me that it's done > within 2 microseconds and then give me an error on my next malloc > because it isn't really done putting it back into place. but that's fine > with me, because of the way that i use memory. i don't mind having > to make friends with the OS. it follows pretty clearly-defined rules.
I just wanted to point out that free() is not a system call. The heap is handled by the C library, and the OS is mostly not involved in it. Anyway, go programmers should probably not be using a whole lot of dynamic memory allocation, and certainly not enough to make the performance of free() matter at all. Álvaro.
_______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
