On Wed, Nov 17, 2010 at 10:03 PM, Chris Adams <cmadams@xxxxxxxxxx> wrote: [snip] > shouldn't be done in a "stable" release of glibc. ÂIs memcpy called > often enough (and on large enough blocks) that this change makes a real > performance difference (not just on a synthetic memcpy benchmark)? Most code is not performance critical. However, performance critical code is performance critical. Memcpy bottle-necked workloads aren't that uncommon. If you've got one you want every piece of memcpy performance possible, if you don't have one then you won't care. Every single performance thing is like this. They add up. If Fedora wanted to carry a patch against GLIBC it could carry one that crashed any application that called memcpy with overlapping inputs. Every one of these bugs would be fixed right quickly. (FWIW, I think the old memcpy would also fail on overlaps, but it would tend to corrupt the ends and only if the ends were within four bytes of each other and the length was one less than a multiple of four or something like that). It's probably a reasonable guess that anything using memcpy incorrectly has other errors arising from a failure to understand and follow the relevant APIs. Although it seems like an easy mistake to makeâ I've valgrinded a lot of code and never seen the valgrind warning for this. I don't think it's actually common. It might be useful to first measure before worrying too much about this. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
