Memory leak

[GoogleCodeExporter]

We've got a memory leak somewhere - 1-3k per second (watch the memory in 
Chrome, it constantly goes up between garbage collections).

Putting in extra code to try and track it down (including disabling a worker 
*really* disabling it (everything except set/get data).

Also running everything through JSLint to try and find any obvious code errors 
(caught a couple already, but nothing relating to this).

The main problem with this in Chrome is that it eventually corrupts the 
settings (before killing the script) - Firefox just ends up eating gigs of 
ram...

Original issue reported on code.google.com by RycochetTM on 4 Jul 2010 at 6:54

[GoogleCodeExporter]

I'm seeing an increase of around 250K per second during idle.  Every so often 
it releases some memory so that increase isn't consistent, but over time it is 
definitely growing.

Original comment by brianbar...@gmail.com on 4 Jul 2010 at 9:22

[GoogleCodeExporter]

Come across an annoying WTF here... It isn't just Golem...

Disabled Golem, and was still getting the large memory leak - disabled FFixer 
and it went down to the small memory leak (really need a native port of 
FFixer...)

Think it's got something to do with the timers that CA itself it using, and how 
badly they're coded... Not sure if I should kill them completely or not - but 
if I do it does mean we need to be *very* accurate with what we're doing to 
replicate them (quite why they went with setTimeout rather than setInterval I 
don't know...)

Back to my ideas and bug hunting...

Original comment by RycochetTM on 4 Jul 2010 at 10:21

[GoogleCodeExporter]

If you kill their timers, we can still grab their initial values on page loads 
right?  Do they ever get reinitialized during ajax page loads?

I would guess that there is some occasional reinitialization that occurs 
whenever the resources (energy, gold, stamina, health) are updated, but that's 
just a guess.

I guess I don't know what you mean by killing their timers, but I would think 
we could just duplicate their timers with better ones if their timer code is 
actually causing a memory leak.  Their timers aren't perfect either.  We could 
always fudge our timers by a second or two too.

Original comment by brianbar...@gmail.com on 4 Jul 2010 at 10:33

[GoogleCodeExporter]

Interesting observation.  If I open a new tab with CA, then close the old tab, 
it looks like the new tab "inherits" the bloated memory from the first CA tab.  
If I instead close the CA tab first, then open a new tab and load CA, it starts 
from scratch.

When the CA page is first loaded and the Golem is first started, I see about 
60-70MB used.  After a few page loads (running a quest, parsing through the 
town, changing generals, etc.) I see 120MB used.  Earlier today I was seeing 
450MB used.

Original comment by brianbar...@gmail.com on 4 Jul 2010 at 10:42

[GoogleCodeExporter]

Somewhat similar here - though I've had it get over a gig before - not sure how 
high it goes, but have come back to the unhappy face a couple of times...

Think they've only got timers for the stats and gold - will look into it again 
in a little while, just trying to make some optimisations etc first ;-)

Original comment by RycochetTM on 4 Jul 2010 at 10:50

[GoogleCodeExporter]

Ok - removed most Golem memory leaks now (I think) - however the biggest memory 
leak appears to be Chrome itself - there's a bug in the AJAX stuff, so go to 
any facebook page and watch it climb - it just climbs faster on apps like 
Castle Age where there's far more being transferred in each request...

Going to leave this issue here in case something else can be done - and until 
Chrome fixes their bug...

Original comment by RycochetTM on 7 Jul 2010 at 3:37

[GoogleCodeExporter]

Apparently latest Chromium (the open source and beta version of Chrome) 
development build has this fixed - so next Chrome update should fix it :-)

Original comment by RycochetTM on 9 Jul 2010 at 2:38

[GoogleCodeExporter]

Ok - memory issues on Firefox seem fixed. Just installed the Chrome Dev channel 
(http://dev.chromium.org/getting-involved/dev-channel) which no longer has the 
same issue and will eventually make it into the release channel (hopefully not 
too long).

Marking this as Fixed, but will make a note on the discussions page regarding 
it.

Original comment by RycochetTM on 10 Jul 2010 at 7:33

• Changed state: Fixed