On 09/04/18 13:58, Henri Sivonen wrote:
Specifically, is it actually useful that nsStringBuffer
uses realloc() as opposed to malloc(), memcpy() with actually
semantically filled amount and free()?

Upon superficial code reading, it seems to me that currently changing
the capacity of an nsA[C]STring might uselessly use realloc to copy
data that's not semantically live data from the string's point of view
and wouldn't really need to be preserved. Have I actually discovered
useless copying or am I misunderstanding?

This came up while discussing allocator APIs for Rust. (The outcome of those discussions is https://github.com/rust-lang/rust/pull/49669 and https://github.com/rust-lang/rust/issues/49668.)

In our new APIs, we could have an additional parameter to realloc that says how many bytes need to be copied. The conclusion was to not add that because:

* Not even the most exotic parts of jemalloc’s non-standard API have something like this, as far as I can tell.

* For vectors, the two common realloc case seem to be pushing one item while already at capacity, and shrinking (perhaps after removing some items) to make the capacity fit the length exactly. In both cases, min(old size, new size) already matches the amount of meaningful bytes.

However these APIs are not stable yet and we can still revisit this if there’s new information or arguments.

Simon Sapin
dev-platform mailing list

Reply via email to