> On Sep 7, 2017, at 17:46, Andrew Trick <[email protected]> wrote: > > >> On Sep 7, 2017, at 5:40 PM, Joe Groff <[email protected]> wrote: >> >> >>> >>>> But then given that, I don't understand why the 'capacity' parameter is >>>> necessary. Under what circumstances would it actually be faster than >>>> "just" calling malloc_size? >>> >>> The runtime may need to hash the address or traverse a lookup table to find >>> out which allocation pool the block resides in. Now, that’s only if some >>> platform ditches full malloc compatibility for user allocations, so I’m not >>> sure how realistic it is. >> >> It seems to me that you could still provide malloc/free compatibility with a >> zone that had to do a relatively expensive traversal on free() to recover >> the pool the memory came from; malloc/free just wouldn't be the ideal >> interface in that situation. >> >> -Joe > > Joe is right, and I just learned how amazing malloc zones are.
As long as you support multiple allocators (or hide everything behind malloc/free), there's already a cost of malloc_zone_from_ptr or equivalent. Without seeing a concrete use case, I wouldn't want to stay with the harder-to-use API in UnsafePointer itself. It might be a feature of a particular allocator that you need to keep the capacity around, but it isn't something generally true about Swift's memory model, and probably never will be. (Interesting reference points: malloc/malloc.h and the implementation of malloc on macOS <https://opensource.apple.com/source/libmalloc/libmalloc-116.50.8/src/malloc.c.auto.html> - search for "free(void *ptr)".) Jordan
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
