Web browsers suck [excrement]
-
Freshly opened Chrome.
WHY IN THE NAME OF FUCK DOES IT NEED THAT MUCH RAM? FUCK ME JAVASCRIPT IS SO FUCKING TERRIBLE.
-
Probably all the infinite scrolling.
-
It does the same thing with pages that are much less discodumb. Fark.com, complete with layout from the 90's, takes 80 fucking megabytes.
-
Addons? Extensions? IDK.
-
-
Addons/extensions generate their own process.
-
yeah discourse started doing that a week or so ago.... i had it at 8GB earlier today, just from browsing.
they have a memory leak somwhere...
-
I always thought it was just Discourse did it, but turns out that's not just the case.
Discourse:
Google:
Both freshly opened windows with the same extensions.
It's not really an issue with 8GB of RAM but it does seem excessive.
When Discourse gets a tab to 2GB+ of memory then that's much more noticeable.
-
HAHAHA.
If you do a heap snapshot of Dicksource on Chrome, there are over 20k+ detached dom elements for this page alone. It looks like they forget to kill dom references in some sort of global cache[] array.
-
wanna see it at 2GB... just open the tab and walk away. it'll get up there in a couple of hours.
-
Oh yeah - I've had it pass that several times. It normally doesn't get much further before offending Chrome and crashing the tab in some way.
-
i'm running 64 bit chrome... larger address space. ;-)
-
Yeah - same here.
-
It looks like they generate 1k more detached dom elements every time someone posts and the thread is open.
This is why people with no experience in real programming should be allowed to do JS.
-
huh... that's odd then.
-
WHY IN THE NAME OF FUCK DOES IT NEED THAT MUCH RAM? FUCK ME JAVASCRIPT IS SO FUCKING TERRIBLE.
Who cares? It's a tiny fraction of your machine's memory, and it'll spend 90% of the time swapped-out.
-
Yes and no. Individually, tiny. But a couple of tabs becomes a couple of gigs quick. And my badass 6-year-old gaming rig only has a couple of gigs to go around.
Also, I have RAM-utilization induced PTSD from having to keep things creaking along at work on 32bit Windows.
-
Why does it have six processes for Hangouts? I have no fucking clue. At least my SSH client uses less memory than a third of Discourse.
-
But a couple of tabs becomes a couple of gigs quick.
Only if none of that memory is shared. Discourse's JavaScript state, of course, can't be shared, but all of the stuff there that's actually the browser is all shared between every tab, so it's no big deal.
And my badass 6-year-old gaming rig only has a couple of gigs to go around.
Well I don't know how many "a couple" is, but I have 8 GB and I've never even gotten remotely close to memory pressure, even while running multiple Discourse tabs and playing Skyrim (and having Steam, Skype, Outlook, etc. open also.) I've gotten to like maybe 65% memory usage. Ever.
Also, I have RAM-utilization induced PTSD from having to keep things creaking along at work on 32bit Windows.
Well there's your problem. Stop doing that.
-
-
My favourite part of people arguing about RAM usage is that so many want to keep things out of RAM, blissfully unaware that that will mean their programs run slower, as the system has to keep falling back to the hard disk
-
I like having half of my RAM used by the OS for caches and the other half running a simulation of a dwarven civil war.
-
-
Almost everybody who bitches about high RAM usage has absolutely no idea how virtual memory works. (Or, if they do, think it still works the same in Windows 8 like it did in Windows XP.)
Of course it didn't help that long into the Vista years, Microsoft's Task Manager didn't really give an accurate picture, since it (incorrectly) marked disposable predictive-cache memory as "in use".
-
having things in RAM that are useful to the program, all good.
having things in RAM that the program is never going to use again and won't GC (leaked objects), ALL BAD!
-
having things in RAM that the program is never going to use again and won't GC (leaked objects), ALL BAD!
Then those programs should free those resources, shouldn't they?
Edit: Is it just me, or does this
look like a cocaine-fuelled Zippy about to perform a 'service' on a particular part of the female anatomy?
-
that's what we've been talking about all along right? it's a bad thing that discourse leaks about 50KB/sec
-
https://ssl.gstatic.com/chat/emoji/4/emoji_u1f61b.png
https://ssl.gstatic.com/chat/emoji/4/emoji_u1f445.png
-
Edit: Is it just me, or does this look like a cocaine-fuelled Zippy about to perform a 'service' on a particular part of the female anatomy?
mmmmmm.... now that you mention it ;-)
-
wanna see it at 2GB... just open the tab and walk away. it'll get up there in a couple of hours.
No wonder I have to close and re-load on my phone every so often.
-
Well there's your problem. Stop doing that.
Trying.At this point I'm to the "trick managers into promising people of authority to EOL our old garbage" stage.
-
At this point I'm to the "trick managers into promising people of authority to EOL our old garbage" stage.
If you succeed, please convince TPTB where I work to replace my PC with something better.
-
Oh! That's easy, accidentally drop some coffee on it if it's a PC or drop it if it's a laptop. Shit happens.
-
Assuming that using a lot of resources means needing a lot of resources. Erroneously I might add.
-
-
Feel my pain on my S3.
-
No wonder I have to close and re-load on my phone every so often.
Oh, that's good. On my ancient S3 mini the poor OS is trying to keep Discurse going at all costs so it crashes my home screen widget (yes, singular), my music player, the bluetooth daemon... Using Discourse on it means all multitasking is right out.
-
If you do a heap snapshot of Dicksource on Chrome, there are over 20k+ detached dom elements for this page alone. It looks like they forget to kill dom references in some sort of global cache[] array.
It looks like they generate 1k more detached dom elements every time someone posts and the thread is open.
QFPTO
There's absolutely no benefit in keeping around stuff you definitely don't need any more, whether the OS is happily paging things out or not.
-
Is chrome not freeing those dom elements, or is discourse hanging onto them in javascript somewhere and keeping them from being GCed?
-
I believe it's not a Discourse thing but of EmberJS. SPA frameworks tend to leak a lot. Because of this the Ember team is moving to a virtual DOM which I'm not sure Discourse is using.
-
Ah yes let's solve the problem of programmers not being competent enough to free DOM references by creating another layer of code to solve the problem! What could possibly go wrong.
-
Incompetent programmers offload their work to incompetent libraries.
For all the pain and suffering Discourse has had due to Ember.js, they could have just skipped the buggy slow library and written it them damned selves. Oh, except, they don't hire any actual programmers, just hacks who can Lego-together Ruby and JS libraries in a way that kind of works half the time.
Nah, I'm being unfair. They're also quite skilled and copying-and-pasting giant RegExes to do Markdown and BBCode.
-
Well, Ember does more that that and memory leaks are a consequence. Anyway, optimize early, die early.
-
Ruby on Rails best programming framework bruh
-
optimize early, die early.
I think they took that advice to the extreme in the opposite direction.
"If early optimization is the worst thing, early de-optimization must be the best thing!" - A brillant dev
-
Now people are moving to more lightweight JS frameworks. A lot of people are moving away from angular to mithril for example.
I think devs are realising that building everything clientside isn't the way to go.
-
I miss the days where server-side technologies were used to prevent bricking your client's machine.
-
Now people are moving to more lightweight JS frameworks. A lot of people are moving away from angular to mithril for example.
Well the big problem from my perspective is people diving face-first into frameworks in the first place.
The framework was designed to solve somebody's problem, but not yours. It very well might have been designed by an idiot who had no clue what he was doing. And once you're hitched to one, the amount of effort to remove the framework is an order of magnitude more than the amount of effort if you had decided upfront to never use it in the first place.
I think people have this attitude "oh well it doesn't matter if it's crappy, we can get it working now and improve it later." The problem is: later never comes. Sometimes you get lucky and you don't need the "later" because Intel and AMD do all the work-- think about, for example, how Windows 95 was grossly inappropriate for computers of its time, but in a couple of years it was fine.
-
I think people have this attitude "oh well it doesn't matter if it's crappy, we can get it working now and improve it later." The problem is: later never comes. Sometimes you get lucky and you don't need the "later" because Intel and AMD do all the work-- think about, for example, how Windows 95 was grossly inappropriate for computers of its time, but in a couple of years it was fine.
That's my thinking too ATM.
SPA's make sense in theory - why would the single server be doing all the work, when you can offload a lot of processing to the makeshift cloud of your users' browsers. Unfortunately, it seems the performance isn't there yet. At least not for complicated applications.
However, I still do think it's the future. It's just makes too much sense to fail. IMO we are now in the early Xerox days of desktop computing. We need someone to come along and make it practical. Probably the hardware guys, as usual.
-
It makes sense to use a MVC framework these days, but they don't have to be as heavy as Ember or Angular. Mithril is like 5kb and does most of the stuff that you want out of an MVC framework.
I prefer to use exactly what I need to get the job done and a lot of people just bung in the kitchen sink.
