Now that I've looked more closely, I take back my earlier "What Ed said." The issue is more nuanced than I originally thought.
> To save everyone having to look at the graph - the initial landing showed a > consistent 20% regression in trace malloc maxheap. If this were a 1-5% > regression, then I think it would be worth discussing the trade-off. At 20%, > I really don't see how we can take this, sorry! :-( As I read the graph, the 20% max-heap regression corresponds to 10mb, which I understand is the expected memory-usage increase here. So it looks like this feature is behaving as intended. To be clear, this regression isn't a 20% regression of memory usage overall; it's pushing the maximum amount of memory allocated on the C++ heap up by 10mb, which corresponds to a 20% regression of maximum heap size in our particular test. I'd like to put the 10mb in perspective based on our telemetry data. Unfortunately we don't have good RSS telemetry numbers on Mac (a direct effect of fixing bug 789975, with no known work-around), so I can't say precisely how much memory the average Mac user uses. I also don't have a CDF in the telemetry front-end (bug 723604), so I can't interpret the data I do have except by eyeballing it. But very roughly I'd guess that the bottom 10% of users are somewhere around 300mb of memory used. A 10mb regression represents a ~1.05x increase in memory usage for these users, which doesn't seem like the end of the world to me. Still my preference would be to be conservative and decrease this down to 5 or 10 screenshots (2.5 - 5mb), which I'd bet most of us could agree is acceptable in terms of memory usage. I'd prefer going down to 5 or 10 screenshots largely because of the precedent it sets: Multiply 10mb of memory times five must-have features and you're talking serious money. After configuring this feature to keep fewer screenshots, we could do the following in parallel: a) Collect data to determine how many screenshots we "need to" keep around, as Asa suggested. Offhand, I'd prefer that we used telemetry instead of test pilot for this, since presumably the usage of this feature will change over time, as people discover it. b) Try to do clever things such as re-rendering bfcached pages, as Andreas suggested. c) Consider adaptive techniques so that users who use this feature heavily will store more screenshots (at the cost of more memory), while those who don't use it won't pay a price. I prefer this "start small" approach of limiting us to 5 or 10 screenshots for four reasons. 0) It lets us land this feature now, rather than after we've tried to reduce its footprint by being clever. Perfect is the enemy of the good and all that. 1) It minimizes the impact on users, particularly those who don't use the feature. 2) It gives the team in charge of this feature an incentive to do (a)-(c) above, all of which would be beneficial even if we were storing 50 screenshots. 3) Most importantly, it sets a precedent that we will configure features to use as little memory as feasible until we have data demonstrating that additional memory would be beneficial, and that if you want to use more than the bare minimum necessary, you need to be clever and avoid making users who don't use the feature pay. -Justin On Tue, Feb 12, 2013 at 6:08 PM, Ed Morley <emor...@mozilla.com> wrote: > On 12 February 2013 22:11:12, Stephen Pohl wrote: >> >> I wanted to give a heads up that we're in the process of finalizing >> the patch for bug 678392 which will give us history swipe animations >> on Mac OSX 10.7+. Since we will be taking snapshots of the 20 >> most-recently visited pages, this will undoubtedly lead to an increase >> in memory utilization on these platforms. > > > To save everyone having to look at the graph - the initial landing showed a > consistent 20% regression in trace malloc maxheap. If this were a 1-5% > regression, then I think it would be worth discussing the trade-off. At 20%, > I really don't see how we can take this, sorry! :-( > > Ed > > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
