
Effectively Managing Memory at Gmail Scale - geobourazanas
http://www.html5rocks.com/en/tutorials/memory/effectivemanagement/
======
TheLoneWolfling
> Game developers, take note: to ensure a 16ms frame time (required to achieve
> 60 frames per second), your application must make zero allocations, because
> a single young generation collection will eat up most of the frame time.

And this is why GC isn't the be-all and end-all solution to memory management.

(As as for people that are screaming "pauseless GC" \- it has throughput
issues [generally due to fine grained locking / other synchronization], and
also often has a performance hit on your main thread [due to locking or read
barriers, generally])

Now, if someone combined a pauseless GC with proper cleanup (i.e. skipping GC
altogether) of variables where the compiler could determine when they can be
thrown away, matters would be different. (So, in other words, the compiler
inserts `malloc` (or whatever) calls, and ensures that every variable created
is either `free`d exactly once after it becomes unreachable or is added to the
set tracked by the GC (or is a constant - especially pertinent with strings).
With (hidden) local variables to track control flow when different branches
cause different allocations.)

~~~
aikah
So basically one needs to re-implement smart pointers in Javascript, right ?

What are the alternative to js style GC,for a language that wouldnt want to
the developper to use manual memory allocation.I've heard about ARC.Are there
other known architectures?

~~~
TheLoneWolfling
As I said: a pauseless GC _with a smart language implementation_ would be
fine. ARC can work, but either requires programmers to prevent loops or needs
a GC regardless.

Object pools at the language level would be an alternative. (I.e. every object
is allocated in a "pool", including pools. When a pool falls out of scope the
entire pool is "freed". You can copy objects between pools as necessary.)

~~~
Dewie
> Object pools at the language level would be an alternative. (I.e. every
> object is allocated in a "pool", including pools. When a pool falls out of
> scope the entire pool is "freed". You can copy objects between pools as
> necessary.)

This might be called "memory regions" in the literature, or at least the work
on using this memory management scheme in an ML (ML Kit).

~~~
nostrademons
Also related to arenas - the main difference is that an arena is a block
region of memory from which different-sized objects are allocated, while a
pool is a collection of same-sized objects. Both are pretty common techniques
in C, C++, and Ada, and pools are common in high-performance Java.

------
TheAceOfHearts
Does anyone else feel like Gmail has actually been getting slower in the past
year?

It feels like it takes a lot longer to load... And once it finally does load,
you still end up having to wait a reasonable amount of time for Hangouts.

~~~
thisjepisje
The old html version is still pretty quick

[https://mail.google.com/mail/u/0/h/](https://mail.google.com/mail/u/0/h/)

------
mccr8
This is a cool article (from last year, FWIW). In particular, I like how
Google uses Chrome browser improvements (the performance.memory API) to fix
bugs in Gmail, and then in turn are able to reflect this back to use Gmail to
notice bugs in Chrome.

This sort of vertical integration that Google is able to do is really powerful
(they were also able to take advantage of this to drive the development of
SPDY), but a little concerning for anybody that has a browser but not a
popular website, or vice versa. Although in this particular case, I don't
think anybody else implements performance.memory, so there would be no easy
way for Gmail to track memory usage in other browsers.

Disclaimer: I work on Firefox and am speaking for myself, etc.

------
corysama
> Anecdotes of Gmail tabs consuming multiple gigabytes of memory on resource-
> constrained laptops and desktops were being heard increasingly frequently

You know, I think I recall being able to run quite nicely featured GUI mail
clients and IRC clients simultaneously on a Pentium 90 with 16 megs of RAM.
And, I expect those clients had an order of magnitude less developer effort
put into them compared to the GMail client-side code. Meanwhile, I'm quite
confident that Gmail team is composed of very, very smart developers. So, what
am I missing? Why does GMail require two orders of magnitude more resources?

~~~
tambourine_man
I often make this kind of argument as well, but the demands we put an email
client through these days are nowhere near what such a machine could handle.

I have around 80.000 messages in my inbox, most of them with attachments
around 10MB, and I can browse and search them instantly.

Then again, I mostly use Gmail's backend, my preferred interface is Mail.app

------
rokhayakebe
Gmail still slow.

Unrelated: Why haven't Google implemented a Google.com-quality-level search
for email?

~~~
napoleond
Gmail's email search is already the best in the space, by far. I'm sure there
are improvements to be made, but zero external pressure to make them.

~~~
lostlogin
Gmail looks particularly good after 5 mins using Apple's search in iClouds
Mail.

------
frik
GMail always had a memory leak problem. Back in the early days of GMail
(2004-2005), Internet Explorer 6 "trident" JS engine leaked memory like crazy.
Manual garbage collection was always needed.

------
Aloisius
It is rather odd to think about "scaling" to a single computer, isn't it? This
is more bloat management than scaling.

~~~
adwf
I was thinking much the same - the Gmail backend surely has scaling issues,
but the frontend should be relatively simple. Afterall, you can still use the
basic html view if you want, the ajax view is just some icing on the cake; it
can't be _that_ resource hungry unless there are bugs.

~~~
robin_reala
There are always bugs in complex applications (especially when JS makes it
this easy) and people leave their Gmail tab open for weeks: not an auspicious
combination.

~~~
adwf
Oh yes, I wasn't trying to criticize that. Every sufficiently large program
will have bugs. It was just that the title implied this was a scaling issue,
rather than a debugging issue.

------
_almosnow
>While JavaScript employs garbage collection for automatic memory management,
it is not a substitute for effective memory management in applications.

And then they continue to make use of the Javascript's GC in order to do
effective memory management... at gmail scale...

~~~
asveikau
It's "no substitute". I read that as: it doesn't free you from thinking about
memory. GC or not, you still need to care about it.

------
aikah
I always found onedrive services to be faster than google drive(the pdf viewer
for instance).It seems that,recently,Gdrive downgraded their default pdf
viewer,while proposing third party alternatives(which is an interesting
system,I'm in the process of developping a good epub viewer for gdrive).

Afaik,what MS does is,as much as possible,do things server side instead of
client side.For instance,online excel calculations are done server side then
the resulting cells are just HTML fragments sent to the ajax callback.

It makes client apps consume way less memory,since less data is stored on the
client.

I have a crappy Android phone (2.x) and onedrive html app doesnt feel slow on
it.On the other hand,I just cant use gmail(ajax versions) or google drive html
apps.They are just not responsive.

