emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs Lisp's future


From: Phillip Lord
Subject: Re: Emacs Lisp's future
Date: Wed, 17 Sep 2014 16:10:40 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> From: address@hidden (Phillip Lord)
>> Date: Wed, 17 Sep 2014 14:54:22 +0100
>> Cc: address@hidden
>> 
>> > - machines still did get faster over the last 10 years (much less so
>> >   than over the preceding 10 years, but also probably much more so than
>> >   over the next 10 years).
>> 
>> Well, Emacs is a text editor. The CPU demands of the task haven't
>> increased that much over the last 10 years either.
>
> You are wrong here.  Emacs 23 added many CPU-intensive features, like
> visual-line-mode.  Emacs 24 added bidirectional display, which makes
> redisplay need roughly twice as much juice as Emacs 23 needed.  And
> these are only two examples that pop up in my head after a 3-sec
> thought; I'm sure there are more.
>
> So it's not like we use up every additional CPU cycle the chips are
> giving us, but we are certainly using significantly more than we did
> 10 years ago.


What can I say? I don't sit around waiting for emacs to do stuff
nowadays when I am using it. And I've just implemented a package that
copies, then searches and replaces an entire buffer on every keypress.
And I don't notice it running for moderate size files.

The manual talks about the performance danger of overlay, but I've just
put an overlay an every word in a 300 line buffer, and I can't notice
that either.

Even though Emacs now takes considerably more than Eight Megabytes, it
is not Constantly Swapping. CPU has grown quicker than Emacs demands.

Phil



reply via email to

[Prev in Thread] Current Thread [Next in Thread]