Re: Optimize glyph row clearing and copying routines

[John Yates <john@yates-sheets.org>]

[-- Attachment #1: Type: text/plain, Size: 1296 bytes --]

Got it.  I jumped to a conclusion based on too little evidence.

/john


On Tue, Sep 24, 2013 at 1:04 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Tue, 24 Sep 2013 09:40:53 -0400
> > From: John Yates <john@yates-sheets.org>
> > Cc: Dmitry Antipov <dmantipov@yandex.ru>, Emacs developers <
> emacs-devel@gnu.org>
> >
> > It is true that the standard's definition of memcpy is in terms of
> copying
> > a sequence of bytes.  It is also true that memcpy is one of the most
> > important and most heavily optimized library functions.
> >
> > These days any credible compiler has a means of determining that an
> > invocation of a function named 'memcpy' is actually an invocation of the
> > standard's memcpy.  E.g. gcc's exposed memcpy is an inline whose body
> > simply calls __builtin_memcpy.
>
> That's not the issue here.  Because this:
>
>   struct foo *foo, *bar;
>   ...
>   *foo = *bar;
>
> (which was the old code) is also implemented with a memcpy, whether
> builtin or not.
>
> The issue here is a _partial_ copy of a struct, starting with some
> offset.  That offset can be aligned less favorably than the struct
> itself, which will cause memcpy be less efficient.
>
> The old code copied the entire struct, and then "fixed" a small number
> of members that cannot be copied.
>
>

[-- Attachment #2: Type: text/html, Size: 1911 bytes --]