This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Do not call memmove when memcpy suffices.

On Tue, Aug 13, 2013 at 05:12:23PM -0300, Alexandre Oliva wrote:
> On Aug 13, 2013, OndÅej BÃlka <> wrote:
> >      char *dest = (_dest);
> >      char *src = (_src);
> >      size_t n = (_n);
> dest, src and n are in the user namespace; we have to use symbols in the
> implementation namespace.
> >      if (__glibc_likely ((size_t)((src - n) - dest) >= 2 * n))
> Is this test really safe?  I'm thinking about arches with segmented
> memory and stuff, so that the difference between unrelated pointers may
> not make much sense or even fit in a size_t.  I'm not sure we support
> any such architecture.
> >        return memmove (dest, src, n);
> If we take this route of optimizing memmove with a macro, we'll probably
> want a distinct symbol to signal that we have already determined that
> there's an overlap and we need the extra complexity, rather than calling
> a function that might perform the test again.
A more fundamental problem is that I looked how is memmove used on my
system. I added counter what is probability of overlap. Just in firefox
it is 
Success probability: 33.95% 
a profile here

I assumed for header that overlaps are rare which is not case here.

I got a result by profiler that is here

and by running

LD_PRELOAD=./ firefox # browse few pages and then close it.
make rep

then copied results directory.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]