792148 - [ARMv6] Disable or reduce Sync support on low-end devices

Status: RESOLVED WONTFIX

(Firefox for Android Graveyard :: General, defect)

Description

[Kartikaya Gupta (email:[e-mail])]

We should investigate how much memory is used by having sync support, and consider removing or reducing sync support if it gets us memory gains.

Comment 1

[Richard Newman [:rnewman]]

Should be ~0 if Sync isn't set up, so I'd mostly be concerned about users being prompted to set up Sync.

My suggestion as a low-effort solution is to not promote Sync on the home page (and maybe not Marketplace, either!) on low-end devices. Simply don't promote a poor user experience.

Beyond that, if there's a clear and easy way that we can determine whether a device is resource-constrained, we can look at reducing limits (e.g., number of history items fetched) within Sync for those devices.

Comment 2

[Kartikaya Gupta (email:[e-mail])]

(In reply to Richard Newman [:rnewman] from comment #1)
> Beyond that, if there's a clear and easy way that we can determine whether a
> device is resource-constrained, we can look at reducing limits (e.g., number
> of history items fetched) within Sync for those devices.

Would this need to be a startup-time check, or can it change dynamically during runtime? (i.e. does sync have knobs that can be adjusted while the app is running to reduce memory usage, or do the knobs only get set on initialization?)

Comment 3

[Richard Newman [:rnewman]]

(In reply to Kartikaya Gupta (:kats) from comment #2)

> Would this need to be a startup-time check, or can it change dynamically
> during runtime? (i.e. does sync have knobs that can be adjusted while the
> app is running to reduce memory usage, or do the knobs only get set on
> initialization?)

Sync has some points that would be suited for adjustment (e.g., number of items processed before flushing a DB batch), but those haven't really been tuned -- for all we know, they're the best balance for a resource-constrained device, given the overhead of DB operations -- so I don't see much point in fiddling with those at runtime.

The main thing I'm thinking of is history download limiting, which mostly applies on a first sync, and definitely doesn't benefit from on-the-fly adjustment -- we would just say "oh, 256MB device? let's grab no more than 1,000 history items in each sync, rather than no more than 5,000". That'll give you a smaller browser.db, which is the big win.

So: wouldn't be "startup-time" in the sense of Fennec's startup, but would occur on a first sync or at the start of each sync.

I'd still be in favor of avoiding promotion of Sync on resource-constrained devices, if we're confident that they can't handle the background work.

Comment 4

[Aaron Train [:aaronmt]]

Wont-fix?

Comment 5

[Richard Newman [:rnewman]]

Unless we have evidence that it's impacting KPIs right now, yes. 

Sync already runs quite infrequently. 

This is something that we should bear in mind for PICL.