![](https://seccdn.libravatar.org/avatar/a895f78a81a109471893519443e4d933.jpg?s=120&d=mm&r=g)
https://bugzilla.suse.com/show_bug.cgi?id=1201884
https://bugzilla.suse.com/show_bug.cgi?id=1201884#c2
Fabian Vogt
MALLOC_PERTURB_ will always touch every newly allocated and every freed memory. That's the whole point of it.
Yes, but I'm wondering whether it goes even further than that:
FWICT, the bottleneck is that add_new_trans calls realloc very often, and glibc treats that like a new allocation + deallocation to be able to overwrite the old data. Maybe that can be optimized somehow?
i.e. does glibc effectively transform realloc into malloc + free or does it realloc like before but just memset the additional space? Because according to the perf report, pretty much all of the realloc cost is spent in _int_free, while I'd expect that a noticable percentage of realloc calls could be expanded in-place. -- You are receiving this mail because: You are on the CC list for the bug.