4 ms·

Terminal emulation and text editors are the obvious ones, notably because DISPLAYING TEXT should be trivially fast in a world of multicore multigigahertz proces

• dahart 5y ago
  That’s a completely different issue than what parent suggested. Terminals aren’t using more resources, they are just going slow - on any hardware, due entirely to lack of devs engineering for perf. Since Casey’s posts, a bunch of terminals and editors have upped their game, started using the GPU for rendering, and are now both faster and more efficient. > allocating several gigs of ram to embed a web renderer […] is the very height of inefficient idiocy. No doubt theres bloat around, but I think you don’t understand web browser allocation strategies. Chrome, Firefox, and Safari are allocating enormous chunks of ram for both caching purposes, and rendering efficiency. It’s extremely difficult to know how much memory is really needed for any given app, you cannot make the assumption that the RAM reported for any given app or page has anything to do with how much the page itself asked for. You also lack justification for calling memory use idiocy if you aren’t running out of memory. As long as there is free memory in the system, it’s fair game, and does not represent inefficiency.
  • fouric 5y ago
    > Terminals aren’t using more resources, they are just going slow "Going slow* is using resources. Clock cycles are a resource. > No doubt theres bloat around, but I think you don’t understand web browser allocation strategies. Using a web rendering engine to render a text editor is still bloated and inefficient. It doesn't matter if web browsers are intrinsically expensive - building a text editor using webtech is the incorrect design decision. > You also lack justification for calling memory use idiocy if you aren’t running out of memory. It should be obvious that the people here aren't complaining about applications that take a trivial amount of memory. In 2021, nobody cares about a text editor that consumes 8 MB of memory. People are complaining about applications that do take up a significant amount of memory and cause you to run out. Mozilla's Firefox hardware report[1] says that just under 25% of Firefox users have only 4 GB of installed RAM. If running on Windows, probably half of that is consumed by the operating system. Suddenly, a 400 MB Electron app is consuming a full fifth of your available memory. That's a real problem, especially for folks that either (1) don't have much money and can't afford a newer machine or (2) want to try to conserve the environment by not spuriously buying new hardware when the old stuff should work. > As long as there is free memory in the system, it’s fair game, and does not represent inefficiency. Maybe by your definition of "inefficiency". Most of the people in this thread are (apparently) using it to mean "using significantly more resources to provide functionality than are intrinsically necessary". This is a much more reasonable definition given that you don't actually know how many resources the user has. [1] https://data.firefox.com/dashboard/hardware https://data.firefox.com/dashboard/hardware
    • kaliszad 5y ago
      The point is, web is everywhere and nobody has to explicitly install anything to use a website - especially important for the less techy people that have no clue about "6 MMU wait states". So the browser is absolutely the right platform to build a (rich) text editor e.g. as a component of a web app. Is it an easy task? No, not really. We still have a half dead IE, Safari and the other browsers are far from perfect. Is that efficient? No. There is a ton of cruft and perhaps the best thing is to draw into a canvas and just not use most of it all (for better performance in the end). So you are basically pushing pixels from JavaScript (ok, or WebAssembly) in the end, if you want the best performance. Then you reimplement all the work that was already done at least 3 times before by OS, Browser and some library/ toolkit/ framework authors. You have to reimplement e.g translation using your own dictionaries, because you cannot easily work with the translator of the browser or the operating system (that's why browsers bring their own). You write a least a slightly different CSS for every browser family. You handle stuff like Content Security Policy differently. This is like every second thing, that you have to reimplement or make platform specific adjustments to make it work somewhat well. That's totally insane. In all this, absolute performance is just really hard to achieve. Do you expect people to ship apps for like 5 different platforms using perhaps 4 considerably different tech stacks or using 1 but then still adjusting for each platform again/ hacking it to look native and not get banned by an app store? The problem is, people don't take responsibility for their work and almost nobody simplifies stuff. Stuff just somehow works but most of it just isn't solid or it isn't compatible or it is extremely (over)complicated. The next guy using it as a dependency has all these problems on top of the problems of his or her own with the problem at hand. This tree is multiple levels deep. Your pyramid is built on stuff that hundreds of smart engineers basically overlooked/ ignored for decades. Meltdown and friends is just one example, there are HW bugs, there are management engines, there is the OS, the libraries, other software/ daemons/ services, bad APIs, old APIs, deprecated APIs, functionality split between old and new API, bug ridden runtime, inconsistent behaviours of a markup language processing and styling implementation etc. pp. We all need to get our act together and the harsh reality is, most of us just don't know everything and there isn't time to know everything. We need basic stuff to really just work and be as simple as possible given the problem domain, else we will not progress without gigantic investments.
    • 5y ago
  • caeril 5y ago
    > Terminals aren’t using more resources Right as I type this, gnome-terminal has 68MB allocated, of which 57MB is resident. My scrollback buffers are limited to 4096 lines and I have 7 tabs open, four of which are sitting on a bash prompt doing nothing. By ANY measure, this is absolutely insane. > you don’t understand web browser allocation strategies You may have missed my point. Rendering TEXT with a library intended to render gmail.com and facebook.com is a ludicrous extravagance. > As long as there is free memory in the system, it’s fair game This is my favorite argument. Just buy more ram, bro. CPUs are super smart bro, caches are magical and you'll always get a hit no matter how much you allocate or how fragmented your heap gets. YOLO. Building software as if DDR4 is just as close to the ALU as L2, that our L2 is fully-associative, that branch prediction and cache hits on vtable dispatch is perfect, then spraying huge numbers of small objects all over the heap, and declaring that all you need to do is buy more RAM, and that halting your application for 6 MMU wait states every dozen cycles is perfectly acceptable. Yes, waiting 20 billion cycles on an amdahl-adjusted basis to move a scrollbar is definitely the future.
    • dahart 5y ago
      > My scrollback buffers are limited to 4096 lines and I have 7 tabs open, four of which are sitting on a bash prompt doing nothing. By ANY measure, this is absolutely insane. Why? Is it using CPU while doing nothing? Scrollback might need at least 4096 lines * 7 tabs * 80 unicode chars =~ 5MB, conservatively. You have 7 child shell environments, and perhaps 7 large bitmaps cached for fast scrolling (I don't know what gnome-terminal caches for rendering, just guessing about what's possible). Plus the program code, the UI code, the terminal fonts. You haven't really explained why 60MB seems like too much to you, let alone "insane". It seems like you're just not accounting for all the features. > Rendering TEXT with a library intended to render gmail.com and facebook.com is a ludicrous extravagance. Why? Isn't it possible if the text rendering library were customized and smaller, that it would then consume more memory because it would be a 2nd library can't be shared with your HTML+CSS renderer, and you need those loaded too anyway? The whole reason the library is big is because it does a lot of things. What reason is there for small/simple uses to not use a library that's already there? > Yes, waiting 20 billion cycles on an amdahl-adjusted basis to move a scrollbar is definitely the future. Your scrollbar takes multiple seconds to respond? Mine doesn't. Your hyperbole notwithstanding, the reasons that browsers speculatively over-allocate is for caching - it is precisely because it's more efficient and performant that way. I didn't write Chrome, but I don't think what they've done is insane.
• Tijdreiziger 5y ago
  > This is to say nothing of the fact that VSCode is the most popular editor on the planet and that the very notion of allocating several gigs of ram to embed a web renderer ( one that is constantly having to be patched for the annual round of UAF vulnerabilities ) in order to DRAW TEXT is the very height of inefficient idiocy. If you just want to draw text, you can simply use Notepad or Notepad++. VSCode has a lot more functionality, though.