On 7/21/20 4:29 PM, Bruno Haible wrote:
However, the algorithm above would be _grossly_ inefficient - especially for
bigger alignments such as 128 or 512.
I don't think performance would be that bad, for many applications at least. I
suppose we could measure overall performance if the topic ever comes up. Of
course this performance issue is mostly just for MS-Windows, as other major
current platforms already have aligned_alloc or rough equivalent.
In a lot of code I've seen, allocation and
deallocation of some data type is done nearby in the code; then it's not
a big burden to use xyz_free for the results of xyz_alloc.
True, and for these, aligned_malloc is OK. But I would rather not have "we
should be compatible with aligned_malloc" leak into a bunch of other modules. As
I see it, aligned_malloc is a crutch for MS-Windows (plus some less-important
nonstandard platforms) and it shouldn't be driving our code or our APIs.
