From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Optimize glyph row clearing and copying routines Date: Tue, 24 Sep 2013 20:04:12 +0300 Message-ID: <83wqm6gnhv.fsf@gnu.org> References: <83a9j2iv6o.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1380042261 30461 80.91.229.3 (24 Sep 2013 17:04:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 24 Sep 2013 17:04:21 +0000 (UTC) Cc: dmantipov@yandex.ru, emacs-devel@gnu.org To: John Yates Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 24 19:04:20 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VOW25-0001Xd-GC for ged-emacs-devel@m.gmane.org; Tue, 24 Sep 2013 19:04:17 +0200 Original-Received: from localhost ([::1]:47183 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VOW24-0000sf-N4 for ged-emacs-devel@m.gmane.org; Tue, 24 Sep 2013 13:04:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43993) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VOW1x-0000sK-Lq for emacs-devel@gnu.org; Tue, 24 Sep 2013 13:04:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VOW1s-00036H-0w for emacs-devel@gnu.org; Tue, 24 Sep 2013 13:04:09 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:48620) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VOW1r-000366-P1 for emacs-devel@gnu.org; Tue, 24 Sep 2013 13:04:03 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MTN006003AU1300@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Tue, 24 Sep 2013 20:04:02 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MTN005ZT3EMRS50@a-mtaout22.012.net.il>; Tue, 24 Sep 2013 20:03:58 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:163612 Archived-At: > Date: Tue, 24 Sep 2013 09:40:53 -0400 > From: John Yates > Cc: Dmitry Antipov , Emacs developers > > 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.