From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Pushing the `gnus-range-*' functions down into the C layer Date: Fri, 10 Sep 2010 15:45:23 +0200 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1284126345 12730 80.91.229.12 (10 Sep 2010 13:45:45 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 10 Sep 2010 13:45:45 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 10 15:45:43 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Ou3vB-0004pp-C8 for ged-emacs-devel@m.gmane.org; Fri, 10 Sep 2010 15:45:42 +0200 Original-Received: from localhost ([127.0.0.1]:56149 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ou3v4-0005Io-Sg for ged-emacs-devel@m.gmane.org; Fri, 10 Sep 2010 09:45:34 -0400 Original-Received: from [140.186.70.92] (port=36142 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ou3uy-0005Ig-Rf for emacs-devel@gnu.org; Fri, 10 Sep 2010 09:45:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Ou3ux-0006Wu-05 for emacs-devel@gnu.org; Fri, 10 Sep 2010 09:45:28 -0400 Original-Received: from impaqm5.telefonica.net ([213.4.138.5]:28883) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ou3uw-0006WO-MH for emacs-devel@gnu.org; Fri, 10 Sep 2010 09:45:26 -0400 Original-Received: from IMPmailhost3.adm.correo ([10.20.102.124]) by IMPaqm5.telefonica.net with bizsmtp id 51Ju1f00U2h2L9m3R1lQvN; Fri, 10 Sep 2010 15:45:24 +0200 Original-Received: from ceviche.home ([83.61.42.227]) by IMPmailhost3.adm.correo with BIZ IMP id 51lP1f00F4u4RdP1j1lQFi; Fri, 10 Sep 2010 15:45:24 +0200 X-Brightmail-Tracker: AAAAAA== X-TE-authinfo: authemail="monnier$movistar.es" |auth_email="monnier@movistar.es" X-TE-AcuTerraCos: auth_cuTerraCos="cosuitnetc01" Original-Received: by ceviche.home (Postfix, from userid 20848) id 69F9D660D2; Fri, 10 Sep 2010 15:45:23 +0200 (CEST) In-Reply-To: (Lars Magne Ingebrigtsen's message of "Fri, 10 Sep 2010 14:35:31 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:129894 Archived-At: > Actually, I think Emacs could do with moving more things down into the C > layer. I mean, having en elisp implementation of sha1 is quite an > achievement, but linking with libgcrypt would have given you that and > much more. Just to take a random example. I won't try to argue that sha1 in Elisp is a good idea, indeed. There's no hard rule here, it's just a general preference for Elisp code. > I don't think the C layer should be considered "second class". It can't be modified from the .emacs, so it is necessarily second class. But of course for functions like sha1 where speed matters and where the functionality and API is stable, C is a better choice. > Anyway, back to the range functions. I think it's slightly generally > useful. I wouldn't dream of arguing that intervals are not generally useful. Hell, we use them for text-properties. But I think that if we want to provide something like that from C, we should try and make them better than just "sorted lists of cons cells". If the code can be shared with the one for text-properties (which uses a balanced binary tree), that's even better. > But I think you kinda underestimate how slow Emacs Lisp is compared to > C. An O(n) function in Emacs Lisp can be slow enough to make it > unpleasant for the user. I know how slow Elisp is, yes. AFAIC it's the only reason why I'd ever consider moving to another language. >> Ah, so you don't just convert to/from lists of points to intervals, but >> you also work directly on intervals. > At present, they're compressed and uncompressed, because memq is much > faster in the general use cases than the Lisp range-member functions. > But if range-memq was present in C, then I'd never uncompress. Hmm... so how 'bout installing a C version of range-memq and keep everything else in Elisp? Would that be good enough as a "quick fix"? Stefan