1236455 - Investigate whether we can sortcut the empty dataset case when clearing form history

Status: RESOLVED WONTFIX

(Toolkit :: Form Manager, task, P5)

Description

[Marco Bonardo [:mak]]

after the removal of canClear in bug 1211849 the time needed to clear form history has increased a little bit
http://alerts.telemetry.mozilla.org/index.html#/detectors/1/metrics/1130/alerts/?from=2015-12-26&to=2015-12-26

This may indicate either canclear was filling some cache that later clear could use (in such a case it's just an ignorable time skew) or we actually spend more time clearing empty datasets.
It would be interesting to investigate whether we can shortcut the empty dataset case or in general recover whatever advantage canClear was bringing to the table.

Comment 1

[Sergey Galich [:serg]]

:mak, is this still relevant? If yes, could you explain a bit more what "clear form history" did you mean?

Comment 2

[Marco Bonardo [:mak]]

The times reported by the FX_SANITIZE_FORMDATA probe look healthy to me at the moment. There's a 0.3% that is still reporting high times (>5s) , but it may just be old and slow machines.
Whether we could improve over it, it's something that may be investigated but I think it is not worth it right now.

By clear form data I meant the formdata sanitizer in Sanitizer.jsm
https://searchfox.org/mozilla-central/rev/918fd22032de3a0025d6e9f4fcc8b7f625315068/browser/modules/Sanitizer.jsm#440-508
That code is currently doing a DELETE and inserting into moz_deleted_formhistory table, that I assume is for Sync, even if I cannot currently find the code reading from that table. There may be some space for micro-optimizations, but with very low priority imo.
Feel free to set priorities differently if you disagree.

Comment 3

[Marco Bonardo [:mak]]

Something interesting, looking at bug 1700584, is that vast majority of crashes in async shutdown include "formdata: blocking" that means formdata is taking a long time to be cleared, or something breaks in a way that we never resolve. That's quite strange, the formdata clear function is really simple: https://searchfox.org/mozilla-central/rev/968bd894205cf4f579d94ac4e175cc3187458605/browser/modules/Sanitizer.jsm#440-506

There's likely 3 things to try and see if the crash volume goes down:

1. The full remove op can likely be optimized, though for someone that has clear history on shutdown the amount of data should be small
2. There's a few code paths that may cause handleCompletion to not be invoked and that would cause the code to wait indefinitely
3. a corrupt db may cause a aquery to run indefinitely, not much likely but not impossible.

I suspect 2) is more likely to be the problem, rather than a missing optimization... the best path forward if there's no more CPP consumers would likely be to change the interface from callbacks to promises, that'd simplify managing errors.

Comment 4

[Sergey Galich [:serg]]

With Bug 1429108 landed, not sure what else can be done here. SQLite is a single writer database, "blocked" is to be expected from time to time for write operations.