From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.devel Subject: Re: Modules: definition of emacs_value Date: Wed, 02 Mar 2016 18:14:48 +0000 Message-ID: References: <56D4D127.5020505@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114b157a118239052d14dc29 X-Trace: ger.gmane.org 1456942529 17169 80.91.229.3 (2 Mar 2016 18:15:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 2 Mar 2016 18:15:29 +0000 (UTC) To: Stefan Monnier , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 02 19:15:20 2016 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 1abBIt-0006BE-NI for ged-emacs-devel@m.gmane.org; Wed, 02 Mar 2016 19:15:19 +0100 Original-Received: from localhost ([::1]:58191 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1abBIs-0001pB-Ta for ged-emacs-devel@m.gmane.org; Wed, 02 Mar 2016 13:15:18 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54386) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1abBIe-0001mp-Tx for emacs-devel@gnu.org; Wed, 02 Mar 2016 13:15:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1abBIa-0005zt-Q0 for emacs-devel@gnu.org; Wed, 02 Mar 2016 13:15:04 -0500 Original-Received: from mail-wm0-x229.google.com ([2a00:1450:400c:c09::229]:34352) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1abBIa-0005yO-Ir for emacs-devel@gnu.org; Wed, 02 Mar 2016 13:15:00 -0500 Original-Received: by mail-wm0-x229.google.com with SMTP id p65so699783wmp.1 for ; Wed, 02 Mar 2016 10:14:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=5n2WH0nF6OTQGEqAb6k3VzBpM4R9+pyxCp8e637ke0Y=; b=BkLZcx9l4kcRKWgG2yOCs+BW8JLW1CwrzsvSlYc5nV7zP1v6DoAANFVlhI9Zal+66A X+dFPlC6kHrI+ThLL9C5W1oGtXq8QwgVOel6KF5QQ8BRWU5ZhZZdDrHIDlahsRca2T5i w4Urbb0SVHK+TUf+S4bwDl5ys2BghojU4yiWPA3jck/oeQrD3GEA/ocrwyLaCObhBQBc YVOhjU06mqVlp2CcL4+UM29jI0d41TpkmsvKlztij0ZNqM7TMKBQt1Rq/ukjXK1O2/4Y hkpM/4MUAtOMpqrBnUAtkZ1Cg2kqn0Nfx7QVJYl+0UMCBbQtr8CwcHRYKsPr6TFChWr4 oaEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=5n2WH0nF6OTQGEqAb6k3VzBpM4R9+pyxCp8e637ke0Y=; b=WXWKGW+HWiM/fFcsevwxSRxdLJmuWwrxJgRm+CNPYtW+qJHcSOI2Rhh1frkOl1/ttz O0xhoAAT03cx5uDtaVzFl83zrd6ItruPXe2bj8NarfmfSGhBtBWa1fgZ1cy/pozkiqD5 iH1MMKYo7TZR9OTuJPaHgOTWs9mma3kfrnQHKfHxG1a89a1JB8LE/LK1AU81ZmkpK4TC xSv2d39MzpnRQjLsHW77+NSb8agtUrNbefV/DLxfBHt22COv+IQDzMLhWppofkLSCMAv ve9WHI0OyXe762y8/O1MRTLK+8MEKt+WYt/QHhEklEYHoLS3KsUk1UEFJzmpEJP4bPPb Zsuw== X-Gm-Message-State: AD7BkJIf+4dLhui8c4OIK1gYWWzh4EA0Xejkdv4pyI2fJ3nHw5q+js1herGU5a0N65G9K+K9u1pExEFEA/z3fA== X-Received: by 10.28.225.8 with SMTP id y8mr1353636wmg.23.1456942498282; Wed, 02 Mar 2016 10:14:58 -0800 (PST) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:400c:c09::229 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:200867 Archived-At: --001a114b157a118239052d14dc29 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Stefan Monnier schrieb am Mi., 2. M=C3=A4rz 2016= um 15:37 Uhr: > > I don't like giving users raw Lisp_Objects. I really don't like making > > 32-bit callers cope with 64-bit values. If emacs_value is a pointer, w= e > > have complete freedom with respect to runtime behavior. Putting a > > Lisp_Object directly in an emacs_value is a false economy. > > This assumes that the performance cost of the API is negligible. > Currently, the performance already sucks rocks because of all the extra > condition-case going on (thanks to your lobbying), but I don't think we > should add insult to injury. > > Is this just speculation, or do you have actual benchmarks? --001a114b157a118239052d14dc29 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Stefan= Monnier <monnier@iro.umontr= eal.ca> schrieb am Mi., 2. M=C3=A4rz 2016 um 15:37=C2=A0Uhr:
> I don't like giving users raw Lis= p_Objects.=C2=A0 I really don't like making
> 32-bit callers cope with 64-bit values.=C2=A0 If emacs_value is a poin= ter, we
> have complete freedom with respect to runtime behavior.=C2=A0 Putting = a
> Lisp_Object directly in an emacs_value is a false economy.

This assumes that the performance cost of the API is negligible.
Currently, the performance already sucks rocks because of all the extra
condition-case going on (thanks to your lobbying), but I don't think we=
should add insult to injury.


Is this just speculation, or do you have a= ctual benchmarks?=C2=A0
--001a114b157a118239052d14dc29--