From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Antipov Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] trunk r117941: Default to stack objects on non-GNU/Linux, non-DOS_NT platforms. Date: Thu, 25 Sep 2014 20:12:01 +0400 Message-ID: <54243ED1.4060708@yandex.ru> References: <837g0sw1yx.fsf@gnu.org> <5423E5B0.4070002@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1411661582 13979 80.91.229.3 (25 Sep 2014 16:13:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 25 Sep 2014 16:13:02 +0000 (UTC) Cc: Emacs development discussions To: Stefan Monnier , Eli Zaretskii , Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 25 18:12:55 2014 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 1XXBex-0001WR-QF for ged-emacs-devel@m.gmane.org; Thu, 25 Sep 2014 18:12:47 +0200 Original-Received: from localhost ([::1]:41067 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XXBex-0007GW-Bh for ged-emacs-devel@m.gmane.org; Thu, 25 Sep 2014 12:12:47 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55626) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XXBeb-0007FC-Bl for emacs-devel@gnu.org; Thu, 25 Sep 2014 12:12:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XXBeU-0000RG-BT for emacs-devel@gnu.org; Thu, 25 Sep 2014 12:12:25 -0400 Original-Received: from forward3l.mail.yandex.net ([84.201.143.136]:32849) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XXBeM-0000NS-BH; Thu, 25 Sep 2014 12:12:10 -0400 Original-Received: from smtp4h.mail.yandex.net (smtp4h.mail.yandex.net [84.201.186.21]) by forward3l.mail.yandex.net (Yandex) with ESMTP id EB2E41501570; Thu, 25 Sep 2014 20:12:02 +0400 (MSK) Original-Received: from smtp4h.mail.yandex.net (localhost [127.0.0.1]) by smtp4h.mail.yandex.net (Yandex) with ESMTP id 344EF2C089B; Thu, 25 Sep 2014 20:12:02 +0400 (MSK) Original-Received: from unknown (unknown [37.139.80.10]) by smtp4h.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id ph0bSuvkLL-C1deBHiQ; Thu, 25 Sep 2014 20:12:01 +0400 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 9688208b-34b1-49bc-af15-0e5f5d6da6c2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1411661521; bh=xc8VyRexlXkI66/46oV7erwb9UFeXskpWtFSMdmiSBU=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=g4VWtTebX7OddpRexiRShQyaLVn0kHis8F7UwqwuRTV2rQO7zZat86rZW2SZRFmta mXwEeejqDKPzpc7DFl1RBOuJyDRWsSWKQrB+/Ox8l4K7EA/ldIwob4B9JXefdHYIZk UiGgKrGsR9ksBrb5z12NLCElAyLfC9Xe4+SZv90U= Authentication-Results: smtp4h.mail.yandex.net; dkim=pass header.i=@yandex.ru User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 84.201.143.136 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:174707 Archived-At: On 09/25/2014 04:52 PM, Stefan Monnier wrote: > Actually, I can't see how workloads will affect the result. Hm...for example, we don't allocate too much stack objects when byte-compile; but we allocate substantial amount of them when attaching text properties in a large buffer. > What kind of feedback do you expect (other than bug-reports)? If I had been aware of this, I would do everything myself. Unfortunately people uses Emacs in a lot of different ways :-). > IIUC the point of this new code is to improve performance Yes. I should say that I've seen small but stable improvements before r117942, but adding extra precautions against stack overflow makes them really negligible. This means that we're going to an overengineered feature with no benefits. IMO we should make it fast rather than commonly used. For example, it's better to avoid local_cons in loops (unless loop is bounded by small compile-time constant) than check against MAX_ALLOCA each time; it may be worth trying to use build_local_string only for a short unibyte compile-time string constants, etc. Dmitry