From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.help Subject: Re: Is Elisp really that slow? (was: Why is Elisp slow?) Date: Sun, 09 Jun 2019 09:46:54 +0300 Message-ID: <8336kjcl29.fsf@gnu.org> References: <87sgtwboot.fsf@telefonica.net> <83muk4obfd.fsf@gnu.org> <20190502214006.4fdsinp7u5xuqvdv@Ergus> <20190503004416.xfuzzucflp6bxpuz@Ergus> <8736lm30lz.fsf@web.de> <864l61j04d.fsf@zoho.eu> <20190511073254.GB29829@tuxteam.de> <20190608085246.GC28228@tuxteam.de> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="259361"; mail-complaints-to="usenet@blaine.gmane.org" To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sun Jun 09 08:47:46 2019 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hZrcH-0015LU-6k for geh-help-gnu-emacs@m.gmane.org; Sun, 09 Jun 2019 08:47:45 +0200 Original-Received: from localhost ([::1]:34098 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hZrcF-0007GP-Lx for geh-help-gnu-emacs@m.gmane.org; Sun, 09 Jun 2019 02:47:43 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39582) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hZrbe-0007GH-8n for help-gnu-emacs@gnu.org; Sun, 09 Jun 2019 02:47:07 -0400 Original-Received: from fencepost.gnu.org ([209.51.188.10]:40637) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hZrbc-0006EZ-Tf for help-gnu-emacs@gnu.org; Sun, 09 Jun 2019 02:47:05 -0400 Original-Received: from [176.228.60.248] (port=1572 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hZrbZ-0003v2-6T for help-gnu-emacs@gnu.org; Sun, 09 Jun 2019 02:47:04 -0400 In-reply-to: (message from Samuel Wales on Sat, 8 Jun 2019 14:00:23 -0700) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:120865 Archived-At: > From: Samuel Wales > Date: Sat, 8 Jun 2019 14:00:23 -0700 > Cc: help-gnu-emacs@gnu.org > > the topic of the thread is elisp speed. it's true that if a > significantly faster single-core-throughput computer existed and > everybody could have access to it, that would solve the problem. but > i don't think it is the question that most of us are discussing in > this particular case. it definitely is not the quesiton i was > addressing. The literal question of whether Lisp can be sped up was answered already: what we have is probably as fast as it can be. Minor improvements are still possible, of course, but they are unlikely to change the situation drastically, where "drastically" meand something like 30% at least. We've hit the wall. That is why there are "out of the box" ideas that float around, like JIT byte-compilation, compilation to native code instead of byte code, etc. Personally, I'm not sure they will bring a significant speedup, but since none of those projects was finished yet, I think we should wait until some of them do before concluding whether any of them show a direction we should go. > >> 1] org mode timestamp [aka "daily/weekly"] agenda to complete faster > >> for a 2 day [...] > > > > Dunno about that. Perhaps Org has sub-optimal algorithms there? > > Why don't you get your hands dirty and profile the whole thing? > > we discussed this on this thread. it is optimized to death. it could > perhaps be rewritten but has not been and that is a large task. and > no, i am not capable of it. and no, that is not the question in this > particular case. the question is, can we speed it up, as the topic of > the thread states, by speeding up elisp. for example with a faster re > matcher. But the re matcher is written in C, and is also optimized to death. Replacing it with another regexp engine is a huge task, certainly not smaller than rewriting the Org agenda code, because Emacs has some unusual requirements from the regexp code (which is why we use a forked version of an old glibc regexp code, and didn't yet succeed to migrate to the current glibc code).