1092588 - Optimize SearchEngines:Data messaging

Status: RESOLVED INCOMPLETE

(Firefox for Android Graveyard :: Awesomescreen, defect)

Description

[Mark Finkle (:mfinkle) (use needinfo?)]

Attachment: SearchEngines-Data.txt

We move a lot of data over JSON when responding to a SearchEngines:Get message.

Doesn't the Search Activity have code to read this directly using Java?

Comment 1

[Mark Finkle (:mfinkle) (use needinfo?)]

Margaret - Do we have Java code for this now? Could this be a mentored bug?

Comment 2

[:Margaret Leibovic]

(In reply to Mark Finkle (:mfinkle) from comment #1)
> Margaret - Do we have Java code for this now? Could this be a mentored bug?

We do have logic in the search activity for reading a search plugin directly from the jar:
http://mxr.mozilla.org/mozilla-central/source/mobile/android/search/java/org/mozilla/search/providers/SearchEngineManager.java#181

This code is very specific to the search activity, so it would need to be generalized if we wanted to use it in Fennec. However, this wouldn't give us information about the order of the search engines, and whether or not some are disabled/hidden, so I don't actually think we should do this as long as we're depending on the Gecko search service (which will probably never change). The "SearchEngines:Data" message is sent pretty infrequently, so I don't think we need to worry too much about optimizing it.

However, one thing we could do would be to split out getting the icons, since that's the majority of the data that's being sent in this message. At some point ckitching might have filed a bug about this, or had ideas about how we could do this.

Comment 3

[Chris Kitching [:ckitching]]

Ah, *this* message. The one where we send favicons across the bridge as base64 inside a JSON string. Every single time we open the sodding URL bar.

This has been bugging me since I spotted it on about day five of my first internship, and I've tried to kill it a few times.

The core of this problem is that we have (or at least, seem to have) no decent way to send binary data between JS and Java. I initially tried to solve that: Bug 903553
That died because, due to the generally poor performance of JS code, it turns out that any serialisation scheme you write in JS is destined to suck more (in terms of serialisation/deserialisation speed) than JSON (which cheats and is handled in fancy native runtime code). My binary format was more compact than JSON, but much slower for most messages due to the serialiser/deserialiser written in JS. A general solution seems to be to patch the VM in some clever way (or something... Does JS have something akin to a JNI that'd allow a decently non-slow serialisation format?), but I rapidly stopped caring.

More recently there was Bug 961600, which doesn't eliminate the stupid message, but at least puts the results of it into the in-memory favicon cache so we're probably going to do it way less often.
Actually, that needs landing again, since it got caught in an earlier backout party.

It would be nice if Java had a nonterrible way to read this data for itself without needing to get it from JS. I don't know enough about the insanity that exists behind the scenes in this subsystem to comment on how hard that'd be, but it'd be nice to be able to avoid sending this message entirely...

Comment 4

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to :Margaret Leibovic from comment #2)

> However, one thing we could do would be to split out getting the icons,
> since that's the majority of the data that's being sent in this message. At
> some point ckitching might have filed a bug about this, or had ideas about
> how we could do this.

Yes. This would be a great optimization. Do the new NativeJSON messaging support binary data? We could stop sending base64 encoded icons as a start. Well, as long as we ever have the icons as binary. We might be pulling them out of the SearchEngine system as base64 to begin with.

Comment 5

[BMO Automation]

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.