See discussion on bug 963477 comment 38. Now we have two schemes of tuning GC/CC to improve app launch time, one is for normal devices and another one is for low memory devices. This bug is for providing a more generalized GC/CC tuning to improve app launch time.

Patrick, Is there anything else needed for this issue since it's dependencies, bug 963477 & bug 971728 have resolved? Thanks, Mike

(In reply to Mike Lee [:mlee] from comment #1) > Is there anything else needed for this issue since it's dependencies, bug > 963477 & bug 971728 have resolved? From my POV I'd say not yet. As discussed in bug 963477 we've got a mechanism that delays GC/CC cycles during application startup but we don't provide a mechanism to prevent other memory-pressure listeners from running. That would need to be addressed IMHO. That being said we might also want to re-evaluate our strategy here in the light of the new devices we're working with. Originally the change in bug 963477 was meant for a single core device with zram. Using our normal minimization procedure for background applications caused high CPU consumption during application launch because of the continuous swapping of pages in and out of the zram swap. This hampered the launching application. Current low-memory devices however will be dual- or even quad-cores with zram thus we can trade CPU time for memory improvements there as we've got plenty of it; that's a luxury we couldn't afford on the Tarako.