On 02/04/14 03:13 PM, comex wrote: > On Wed, Apr 2, 2014 at 12:25 PM, Daniel Micay <danielmi...@gmail.com> wrote: >> Without a size parameter to `free`, an allocator needs to track the size >> of allocations manually. It increases the memory overhead, along with >> adding bookkeeping overhead. > > Not by very much... If a chunk's header is stored externally, like > tcmalloc and Linux slub, there is virtually no memory overhead at the > cost of free involving a quick hash table lookup on the address; if > it's stored internally, like jemalloc, the overhead is just possibly > some page-size-remainder wastage, and free just masks the pointer. > Either way, if chunks are ever going to be freed, you need some kind > of header to count free slots.
You're talking about allocators designed around the limitation of an API. The design no longer needs to make the same compromises if you're going to know the size. The difference between no cache miss and a cache miss is not insignificant... > I guess knowing the size would help the fast path for free be really > simple and even inlined, since it could just swap a fixed thread-local > variable. It's a significant optimization. There's a reason this was included in the C++ allocator design and is being extended to more of the language in C++14. > But is that really worth hanging language features on, one way or the other? Is it really worth designing the language around the micro-optimization of leaving off a capacity field? Rust's syntax is verbose enough without needing to convert to and from vector/string builders all the time.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
