From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Leake Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Mon, 16 Feb 2015 09:25:31 -0600 Message-ID: <85iof1anf8.fsf@stephe-leake.org> References: <83y4oiiw81.fsf@gnu.org> <838ugdf251.fsf@gnu.org> <54D80098.3020209@cs.ucla.edu> <54D85304.1030600@cs.ucla.edu> <54D9AC29.2020603@cs.ucla.edu> <54DA8539.1020905@cs.ucla.edu> <87zj8ktq8f.fsf@lifelogs.com> <54DD6413.1000403@cs.ucla.edu> <83wq3m436s.fsf@gnu.org> <834mqowbnh.fsf@gnu.org> <85egpsgf5z.fsf@stephe-leake.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1424100386 19594 80.91.229.3 (16 Feb 2015 15:26:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 16 Feb 2015 15:26:26 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 16 16:26:15 2015 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 1YNNYo-000744-5z for ged-emacs-devel@m.gmane.org; Mon, 16 Feb 2015 16:26:10 +0100 Original-Received: from localhost ([::1]:40235 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YNNYn-00029B-75 for ged-emacs-devel@m.gmane.org; Mon, 16 Feb 2015 10:26:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45096) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YNNYZ-00028b-M3 for emacs-devel@gnu.org; Mon, 16 Feb 2015 10:25:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YNNYW-000454-LZ for emacs-devel@gnu.org; Mon, 16 Feb 2015 10:25:55 -0500 Original-Received: from gproxy1-pub.mail.unifiedlayer.com ([69.89.25.95]:42628) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1YNNYW-000442-E6 for emacs-devel@gnu.org; Mon, 16 Feb 2015 10:25:52 -0500 Original-Received: (qmail 1185 invoked by uid 0); 16 Feb 2015 15:25:48 -0000 Original-Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy1.mail.unifiedlayer.com with SMTP; 16 Feb 2015 15:25:48 -0000 Original-Received: from host114.hostmonster.com ([74.220.207.114]) by cmgw4 with id tARd1p00R2UdiVW01ARgwR; Mon, 16 Feb 2015 15:25:46 -0700 X-Authority-Analysis: v=2.1 cv=GubRpCFC c=1 sm=1 tr=0 a=CQdxDb2CKd3SRg4I0/XZPQ==:117 a=CQdxDb2CKd3SRg4I0/XZPQ==:17 a=DsvgjBjRAAAA:8 a=f5113yIGAAAA:8 a=TeMFXEv2S7AA:10 a=9i_RQKNPAAAA:8 a=hEr_IkYJT6EA:10 a=jrwKn-8xaegA:10 a=0HtSIViG9nkA:10 a=1JBwfGLeX0HzBgAmyCgA:9 Original-Received: from [70.94.38.149] (port=52958 helo=takver) by host114.hostmonster.com with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.82) (envelope-from ) id 1YNNYJ-0001WQ-1j for emacs-devel@gnu.org; Mon, 16 Feb 2015 08:25:39 -0700 In-Reply-To: (Stefan Monnier's message of "Sun, 15 Feb 2015 14:30:21 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (windows-nt) X-Identified-User: {2442:host114.hostmonster.com:stephele:stephe-leake.org} {sentby:smtp auth 70.94.38.149 authed with stephen_leake@stephe-leake.org} X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 69.89.25.95 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:183165 Archived-At: Stefan Monnier writes: >> This is the model I had in mind. Since I need max speed with mixed >> Ada/lisp code, I need tight integration with the core. The people who > > The non-tight integration will mostly impact uses of things like CONSP, > XCAR, XCDR, ... but I'm far from convinced that making those go through > function calls would slow you down enough to make much of a > difference. Ok. I'm willing to go with a non-tight implementation and see how fast it is. > Of course, we should provide functions to get efficient access to the > buffer text, along the lines of INC_BOTH, and FETCH_CHAR. Yes, the parser does need efficient access to the buffer text. Although one option is to keep the current elisp lexer, and only pass tokens to the module parser. Lots of things to benchmark :). -- -- Stephe