I feel like no project should be allowed to advertise itself as "fast" unless it presents at least one (1) measurement demonstrating it.
base64 /dev/urandom | head -c 1000000000 > file.txtThough I take the point: if a text editor advertises itself as being "fast", this is the kind of stuff you expect it to handle.
EDIT: ok, so i just tried the hexdump version. Vim and Emacs took a couple of seconds each (Emacs being slightly slower and chunkier when you navigate, Vim handles it without issue and is perfectly repsonsive). less opened it instantly (obviously, it's less!). ox has been going for a few minutes now, nothing happening.
It's not the benchmark's fault, ox is just slow for large files.
XML and JSON without pretty print. Minimized HTML with embedded resources. While not often gigabyte sized those seem to be enough to get most editors to hang and make editing the files a miserable experience.
However, ox clearly performs poorly even when your text files aren't massive single lines, so it doesn't really matter: ox basically can't handle files like this regardless of line distribution.
Older Unixen at least (SVR3-based) had a tool called bfs - big file scanner. Used it some, e.g. when, as a system engineer, I helped IT staff of one of our customers, a university processing exam results of tens of thousands of students from dozens of colleges affiliated to that univ. IIRC, its UI was something like a read-only ed (google "unix bfs command"). You used it to scan really large (for the time) files, e.g. data files (input/output) in large data processing environments, for purposes like checking if the input or output files anecdotally looked okay, no major noticeable garbage in them. Haven't checked if it is present in modern Linuxes. Also don't remember if it could handle large files without newlines. Likely not, if based on ed. Didn't have such files to work on then.
(It'd be fine if not all features worked on these files.)
Sure, most files are reasonably sized and shaped, but sometimes you do find yourself needing to e.g. dig into that single-line 1GB json file to try to debug something, and it's inefficient to have to think, before opening any file, "is more normal tool sufficient for this, or should I use something else?"
There's no fundamental reason we can't have one tool that does it all!
[1] https://www.gnu.org/software/emacs/manual/html_node/emacs/Lo...
my ideal editor would never block, and use file-sized based approximations to allow scrolling to arbitrary locations w/o having to actually read the contents of the entire. things like syntax highlighting &c would be either strictly time-limited to not drop frames, or done in the background.
Edit: Oops, posted some misinformation. The mistaken part, reproduced below:
> First, wrapping by default only occurs when writing to a tty. When stdout is redirected to a file, wrapping base64 output usually doesn't make sense, so wrapping doesn't happen.
Correction: coreutils base64 wraps regardless of whether stdout is a tty.
Yes it does. "-b N" or "--break=N" inserts a line break every N characters.
$ base64 /dev/urandom | head -c 1000000000 | wc
0 1 1000000000
Most of the time I only realize that everything is on a single line after opening the file.
A good editor doesn't require me to think about these things.
I don't want to chase separate tools that can format different text files, that's what editors are for.
The important thing to realize is that text editor performance is less about the technology used and more about the data structures and i/o.
Personally i see no reason why this is needed (just use vim), but I'm sure a lot of people will use it just because its written in rust^^
Unfortunately it's not automatable.
It also looks like vim and emacs don't decide what a realistic use case is, or if you're "most" users/developers. They just open text files for editing.
Even for large files, I've never noticed anything beyond microsecond-type delays with those. Definitely does not feel laggy to me, usually.
My beloved vim doesn't fair so we'll. VScode does very well on this.
I often find it's much faster to pipe out to a command line program to do formatting on huge files.
e.g.
:%! jq
:%! xmllint --format -i.e. I would have done:
:! jq %
:! cat % | ...I've always wanted to be able to try and verify performance bounds at the CI stage, and I'm hesitantly optimistic it can be done cleanly (although amortized analysis is extremely important, you can actually play "guess the C++ std container from the graph" if you plot the data right)
\s
Development speed of applications in Python compared to raw assembly is nearly infinitely faster, both because it’s easier to write and because the talent pool for ASM is near zero in most cities.
But the same can be said for basically all metrics people use to sell products.