From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?iso-8859-1?Q?Jan_Dj=E4rv?= Newsgroups: gmane.emacs.devel Subject: Re: Inlining doesn't happen on OS X: big performance problem Date: Fri, 20 Sep 2013 08:14:29 +0200 Message-ID: <68974C3C-AD25-404F-8C13-834B234C7660@swipnet.se> References: <523AFDA5.4030607@dancol.org> <87y56s3h2f.fsf@igel.home> <523B656E.7020700@dancol.org> <523B6A30.3020406@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1379657687 8057 80.91.229.3 (20 Sep 2013 06:14:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 20 Sep 2013 06:14:47 +0000 (UTC) Cc: Daniel Colascione , Emacs development discussions To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 20 08:14:49 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 1VMtzM-0008AM-AF for ged-emacs-devel@m.gmane.org; Fri, 20 Sep 2013 08:14:48 +0200 Original-Received: from localhost ([::1]:54240 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VMtzL-0004HV-R7 for ged-emacs-devel@m.gmane.org; Fri, 20 Sep 2013 02:14:47 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34599) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VMtzE-0004HJ-A5 for emacs-devel@gnu.org; Fri, 20 Sep 2013 02:14:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VMtz8-0004Eh-9g for emacs-devel@gnu.org; Fri, 20 Sep 2013 02:14:40 -0400 Original-Received: from mail01.bdtv.se ([176.10.222.34]:55205) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1VMtz7-0004EH-T1 for emacs-devel@gnu.org; Fri, 20 Sep 2013 02:14:34 -0400 Original-Received: (qmail 847 invoked by uid 89); 20 Sep 2013 06:14:29 -0000 Original-Received: from h-46-59-42-57.na.cust.bahnhof.se (HELO coolsville.localdomain) (boel.djarv@bdtv.se@46.59.42.57) by mail01.bdtv.se with ESMTPA; 20 Sep 2013 06:14:29 -0000 Original-Received: from [172.20.199.13] (unknown [172.20.199.13]) by coolsville.localdomain (Postfix) with ESMTPSA id D06E61A010E; Fri, 20 Sep 2013 06:14:28 +0000 (UTC) In-Reply-To: <523B6A30.3020406@cs.ucla.edu> X-Mailer: Apple Mail (2.1510) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 176.10.222.34 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:163497 Archived-At: Hello. 19 sep 2013 kl. 23:18 skrev Paul Eggert : > On 09/19/13 13:58, Daniel Colascione wrote: >> I don't see why we've been going through the tree and replacing >> instances of "static inline" with "static" >=20 > See bug#12541; removing the "inline" helped performance slightly = there. >=20 > More generally, these days "inline" is mostly a noise word for static > functions, just as "register" is a noise word for locals. Modern > compilers inline static functions pretty well without "inline", just > as they allocate registers pretty well without "register", and it > saves maintenance hassle if developers don't have to waste their > time reading the "inline" noise and worrying about whether the > "inline" should be there. Please do not try to motivate the current Emacs inline handling with = saved maintenance hassle. Maintenance is now a magnitude worse than = before due to the complicated inline handling. Before: 1) See INLINE in code. 2) Check out INLINE define in config.h 3) Write your new INLINE function. Now: 1) See SYSTEM_INLINE in code. 2) Find where it is defined, 2 places, either to INLINE (as _GL_INLINE) = or EXTERN_INLINE (as _GL_EXTERN_INLINE). 3) Figure out if INLINE or EXTERN_INLINE applies to the case at hand. 4) Find definition of _GL_INLINE and _GL_EXTERN_INLINE. 5) Manually parse complicated conditionals to see which define applies. 6) Sigh when you realize that there are unique preprocessor defines of = inline per file. 7) Don't use inline as it is too complicated and convince yourself that = is is OK as machines gets faster and faster. Also note that there are still 'static inline' in the w32-code, so if I = saw that, I might come to the conclusion that 'static inline' is OK. I'm sure there is some motivation for the inline mess we have now, but = performance is not it (previously we had fast macros) and maintenance is = absolutely not it either. Jan D.