71–80 of 84 posts
I posted the same content 5 days ago here: https://news.ycombinator.com/item?id=23021574 No reaction at all. I am really curios to understand what I did wrong at the time.
Earlier quoted context omitted.
My experience is it's generally either - inefficient font-lock regexes, which are rarely benchmarked / optimized since most files don't have long lines and because font-lock behavior is quite complicated to begin with; - inefficient thing-at-point implementations / use, e.g. an O(n*n) thing-at-point called at various points by an O(n) function; - modes using font-lock regexps where they really just need "fixed" style…
Emacs dev here. The primary cause is something else. Emacs's inefficiency in handling files with long lines is due to two factors: (a) The primitive unit of work for the display engine (the code that determines how to combine text, font metrics, syntax highlighting, inline image display, etc.) is a line (a newline-delimited span of characters). (b) The redisplay routine is called very frequently—not just when the scr…
That's an interesting question. My other guess would have been Gimp, and based on a quick glance at Debian's popcon, I'd say Gimp might be slightly in the lead.
Then again, like Open Firmware deployed Forth on millions of computers, right under our noses, it would not surprise me at all if there were a simple Lisp implementation hidden on every computer in the world.
Is there anything more recent than DSSSL?
It took me 124.98 mins to build the native-comp branch with a 4-cores/8-threads i7-4790k, 32GB RAM on a LXC instance while the master branch took me 244 seconds. Both branches are obtained from latest available git snapshot as 2020-5-4 20:20 CDT.
The following function is passed to (benchmark-run-compiled 10 ...) for each run.
;; -*- lexical-binding: t -*-
(require 'cl-lib)
(defun bf-1 nil
(/
(apply '+
(cl-loop repeat 300000
collect (cl-random 1.0)))
300000.0))
Before each run, (garbage-collect) function is called.
With Emacs's built-in core lisp functions, cl-lib functions and the above benchmark function are all native-compiled, it took 0.5823 second to complete.
With Emacs built-ins and cl-lib are native-compiled but the benchmark function is byte-compiled, it takes 0.6411 second to complete.
With byte-compiled Emacs built-in/cl-lib/benchmark functions, it takes 1.3574 second to complete.
With byte-compiled Emacs built-in/cl-lib functions and interpreted benchmark function, it takes 78.054 seconds with 1 GC taking 75.094 second, which implies the execution roughly takes 2.96 seconds.
I also ran same benchmark on a 4-core A10-6800k. and observed similar ratios on the builds from 2020-5-3.
Earlier quoted context omitted.
Emacs dev here. The primary cause is something else. Emacs's inefficiency in handling files with long lines is due to two factors: (a) The primitive unit of work for the display engine (the code that determines how to combine text, font metrics, syntax highlighting, inline image display, etc.) is a line (a newline-delimited span of characters). (b) The redisplay routine is called very frequently—not just when the scr…
I’m not an Emacs dev so I’ll concede your expertise here - but if it is fundamental to the core navigation and redisplay, why does “stepping down” modes help so much? Fundamental and text mode certainly aren’t great with long lines, but are usually orders of magnitude better (eg a few seconds per command instead of 10s of seconds). (I have not tried so-long-mode and am mostly on Emacs 26 with some 25.)
Consider an ostensibly simple operation like determining the column in which a particular character appears. The answer to that isn't the number of characters since the last occurrence of `\n`, because whatever modes are active can inject arbitrary spacing, or display particular strings as something shorter or longer (a trivial example is the mode that causes `lambda` to be displayed as `λ`), or cause some characters to be displayed in a non-roman font where a single glyph is more than one column wide, and so on. To determine the character's column accurately you need to take into account everything that could affect how you'd paint the screen at that position, i.e., run the whole redisplay loop for some portion of a buffer. The richer the set of active modes, the more expensive it is to do that and the more often it is done.
As a exclusive emacs user for the last 20 years, I'm quite excited; my main complain about emacs is its slow down with some more sophisticated packages. I wonder if it improves magit performance with large codebases. Pigs fly just fine with with enough thrust.
One reason magit is slow (that last I checked still hasn't been fixed) is that it spawns a large number of processes calling out to git for each operation. Most of these are redundant and could/should go away with either a redesign or a working caching scheme. This issue is more than obvious on platforms (e.g. some macOS versions) where fork/vfork are not as fast as one would expect. I like the paradigm behind magit,…
Earlier quoted context omitted.
Rewriting thousands of packages (some of which have had man-decades of work poured into them) would also be rather convoluted.
I wonder whether a modern modularized architecture might be the better way to handle this. Similar to neovim where you have a backend which communicates with a detatched frontend and other backends over some rpc-mechanism. Refactor the existing emacs to work headless and become the legacy-core, while also establishing channels to attatch any other core and frontend.
Note: this is a video. Here are the slides: http://akrl.sdf.org/gccemacs_els2020.pdf
I'd recognize a LaTeX beamer presentation anywhere. Here is the corresponding paper: https://arxiv.org/pdf/2004.02504.pdf