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: Benchmarking temporary Lisp objects [Was: Re: [RFC] temporary Lisp_Strings] Date: Mon, 08 Sep 2014 14:33:07 +0400 Message-ID: <540D85E3.5090407@yandex.ru> References: <5405BE5D.1090003@yandex.ru> <5405DE8B.4050201@yandex.ru> <5406EC21.4060200@yandex.ru> <5407281C.3090302@cs.ucla.edu> <54073621.2040403@yandex.ru> <540744F5.2010804@cs.ucla.edu> <5407F1B7.6090704@yandex.ru> <5407F4E6.2040809@cs.ucla.edu> <5407FDF4.7020504@yandex.ru> <54086B1A.8070506@yandex.ru> <54087B5E.10402@yandex.ru> <54088D63.8010406@cs.ucla.edu> <54093561.2010507@yandex.ru> <5409630B.6030201@cs.ucla.edu> 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 1410172426 11788 80.91.229.3 (8 Sep 2014 10:33:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 8 Sep 2014 10:33:46 +0000 (UTC) Cc: Emacs development discussions To: Stefan Monnier , Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 08 12:33:39 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 1XQwGQ-0006zo-KI for ged-emacs-devel@m.gmane.org; Mon, 08 Sep 2014 12:33:38 +0200 Original-Received: from localhost ([::1]:42127 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XQwGQ-0007n9-65 for ged-emacs-devel@m.gmane.org; Mon, 08 Sep 2014 06:33:38 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34979) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XQwG8-0007ms-Dj for emacs-devel@gnu.org; Mon, 08 Sep 2014 06:33:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XQwG1-0001NV-Dv for emacs-devel@gnu.org; Mon, 08 Sep 2014 06:33:20 -0400 Original-Received: from forward7l.mail.yandex.net ([84.201.143.140]:40352) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XQwG1-0001ND-2x for emacs-devel@gnu.org; Mon, 08 Sep 2014 06:33:13 -0400 Original-Received: from smtp18.mail.yandex.net (smtp18.mail.yandex.net [95.108.252.18]) by forward7l.mail.yandex.net (Yandex) with ESMTP id C0C8CBC1867; Mon, 8 Sep 2014 14:33:09 +0400 (MSK) Original-Received: from smtp18.mail.yandex.net (localhost [127.0.0.1]) by smtp18.mail.yandex.net (Yandex) with ESMTP id 1FC8718A031A; Mon, 8 Sep 2014 14:33:09 +0400 (MSK) Original-Received: from unknown (unknown [37.139.80.10]) by smtp18.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id XXFqU36XaK-X808FsnE; Mon, 8 Sep 2014 14:33:08 +0400 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 78fdd934-036f-436c-a1b5-c4d03fb9b2f6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1410172388; bh=a5Tcm+BEGSDL2o6gjuSm+TO34cZzcQ9S9gGUkQmZD0U=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=VgNYXM2stJz3iUofCi06PfJBebAinaG8oDRewJBS/tjQVyUGUwxwOzGGgfpFIDQo+ he0qmcaGQ1Bi3dbjZfikFQ3mFiPWTciFXHqDEl6l2rwuM15j5OKwgZRXH5Y+/m9PQv 2tIR0nOoSDe99MCkuT6oGV/izDrAX5VJdHKezo4Y= Authentication-Results: smtp18.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.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 84.201.143.140 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:174078 Archived-At: On 09/05/2014 07:35 PM, Stefan Monnier wrote: > I'd expect that such escaping would only occur in "unusual setups", as > a result of later unrelated changes. E.g. an alloca_string object is > passed to DECODE_FILE or to Fexpand_file_name, which will usually stay > within C code or even if it escapes to Elisp its lifetime will not > escape the stack discipline. > > And some times later we get random crashes in odd situations because > someone figure a clever way to do god-knows-what (e.g. speed things up > via a memoization) by storing those refs into some global table. Surely such an errors are possible. But if we use alloca in general, there is always a possibility for someone to misuse pointer returned from it, no matter whether that pointer is used for Lisp_Objects or not. Any developer good enough in C should be able to find, track and fix this class of errors, so I don't see a problem here. > Basically, this risks making Elisp's semantics more murky, so it has to > come with a good performance story. In somewhat corner cases where an allocation speed is really important, we can get a very good story. For example, using build_local_vector instead of Fmake_vector in Ffind_charset_region makes this function ~18x times faster (for reatively large buffers): (defun test-charset () (interactive) (let ((start (float-time)) (max (1- (buffer-size)))) (dotimes (i max) (find-charset-region (1+ max) (+ max 2))) (message "%fs elapsed" (- (float-time) start)))) Of course, no one should detect charsets by scanning buffer in such a way, but I found this example very illustrative. And I believe that no one can design an example where using alloca introduces a 18x slowdown :-). Dmitry