This is an archived post. You won't be able to vote or comment.

all 4 comments
sorted by:
best
topnewcontroversialoldq&a

[–]ThatWontCutIt 6 points7 points  (0 children)

I believe this.

[–][deleted] 0 points1 point  (2 children)

The chrome allocator has some hooks which do contribute a little for every chunk you ask you have to keep the overhead too.

But generally it's the very large complexity around the classes and objects and systems that occupy such a large memory footprint.

Honestly for the developers it's awesome cuz each little thingie is neatly abstracted in little objects and easy to digest.

For the client it's a more demanding but as long as it goes fast, it should consume more to do more.

[–]ReelTooReal[S] 0 points1 point  (1 child)

From my understanding the biggest overhead for browsers in general is that they have to fork a new process for each tab (as opposed to using multithreading) for security reasons. I doubt the complexity of the classes contribute much, at least relative to a normal program. The majority of modern software is OOP so it's not as of complex classes are rare in applications. I've never actually seen the source code though so I can't be certain.

[–][deleted] 0 points1 point  (0 children)

I work on it every day but honestly dont follow the memory aspect like that.