4 ms·

> 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 t

by 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.

by caeril 5y ago

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.