On 2/12/2013 8:05 PM, Andreas Gal wrote:
Hey Asa,
where does the magic 20 pages deep history number come from? Why not 1? Or 999?
Andreas
The goal of the feature is to work when ever the user engages it and not
just "for the first couple of pages".
Just have one and too many users would fall off of their back stack very
quickly. Nine hundred ninety nine and we'd be wasting memory for all but
a very small minority of users who accumulate and navigate through that
much history.
We have Test Pilot data we could use to fine tune this, maybe we only
need 15, or maybe we actually need 25.
My point isn't to quarrel about the depth of that back stack, but to say
that it is not OK to simply dismiss a new feature because it increases
memory footprint. Features vs footprint is a balancing act. Both sides
must be weighed and that wasn't what I saw happening here. What I saw
happening was the out of hand dismissal of a feature based on no
consideration other than increased memory footprint. That cannot be how
we roll.
- A
On Feb 12, 2013, at 9:40 PM, Asa Dotzler <a...@mozilla.com> wrote:
On 2/12/2013 3:08 PM, Ed Morley 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
I don't see how we can *not* take this. Of course it's going to mean using more
memory. If it doesn't leak, and it doesn't put us over some magic limit where
a significant portion of our users end up paging or something like that, then I
don't see how we can reject it.
Without context, 1-5% or 20% growth are just meaningless numbers. The context
here is not some accidental regression or a feature doing something horribly
wrong with memory. This is simply a memory-expensive feature and it's a feature
we *must* land.
I'm all for smart people looking for ways to get this memory usage as low as it
can be without undermining the value of the feature, but if we cannot find
those wins, we should land this as it is.
- A
_______________________________________________
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
