[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Shrinking the C core
From: |
Po Lu |
Subject: |
Re: Shrinking the C core |
Date: |
Thu, 10 Aug 2023 10:28:28 +0800 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
"Eric S. Raymond" <esr@thyrsus.com> writes:
> Yes, in fact, I can. Because if by some miracle we were able to
> instantly rewrite the entirety of Emacs in Python (which I'm not
> advocating, I chose it because it's the slowest of the major modern
> scripting languages) basic considerations of clocks per second would
> predict it to run a *dead minimum* of two orders of magnitude faster
> than the Emacs of, say, 1990.
The important measure is how much slower it will be compared to the
Emacs of today. The Emacs of yesteryear is not relevant at all: simply
grab a copy of Emacs 23.1, and compare the speed of CC Mode font lock
there (on period hardware) to the speed of CC Mode font lock on
contemporary hardware today.
> They were too obvious, describing problems that competent software
> engineers know how to prevent or hedge against, and you addressed me
> as though I were a n00b that just fell off a cabbage truck. My
Projecting much?
I raised those concerns because I have seen them and suffered their
consequences. There is no place for hubris: analogous changes were also
performed by equally skilled and experienced Emacs developers, only for
issues to be uncovered years in the future. (For example, when a call
to `with-temp-buffer' was introduced to loadup.)
How many times must we suffer the consequences of indiscriminate
refactoring before we will recognize the obvious conclusion that
code which doesn't need to change, shouldn't?
> earliest contributions to Emacs were done so long ago that they
> predated the systematic Changelog convention; have you heard the
> expression "teaching your grandmother to suck eggs"? My patience for
> that sort of thing is limited.
If that is the attitude by which you treat other Emacs developers, then
from my POV this debate is over. We cannot work with you, when you
dismiss real-world concerns that have been seen innumerable times in
practice, based on a conceited view of your own skill.
Which, BTW, has already broken the build once. And the jury is still
out on whether your earlier change needs to be reverted, since Andrea
has yet to ascertain if it will lead to negative consequences for native
compilation.
- Re: Shrinking the C core, (continued)
- Re: Shrinking the C core, Eric S. Raymond, 2023/08/10
- Re: Shrinking the C core, Emanuel Berg, 2023/08/11
- Re: Shrinking the C core, Eli Zaretskii, 2023/08/11
- Re: Shrinking the C core, Emanuel Berg, 2023/08/11
- Re: Shrinking the C core, Eli Zaretskii, 2023/08/11
- Re: Shrinking the C core, Emanuel Berg, 2023/08/11
- Re: Shrinking the C core, Eli Zaretskii, 2023/08/11
- Re: Shrinking the C core,
Po Lu <=
- Re: Shrinking the C core, Christopher Dimech, 2023/08/10
- Re: Shrinking the C core, Eli Zaretskii, 2023/08/10
- Re: Shrinking the C core, Eric S. Raymond, 2023/08/10
- Re: Shrinking the C core, Christopher Dimech, 2023/08/10
- Re: Shrinking the C core, Immanuel Litzroth, 2023/08/11
- Re: Shrinking the C core, Eli Zaretskii, 2023/08/11
- Re: Shrinking the C core, tomas, 2023/08/11
- Re: Shrinking the C core, Eli Zaretskii, 2023/08/11
- Re: Shrinking the C core, Emanuel Berg, 2023/08/11
- Bignum performance (was: Shrinking the C core), Ihor Radchenko, 2023/08/11