We’re still whittling away at the startup time on Android. Shilpan Bhagat took a crack at speeding up parsing profiles.ini. Brian Nicholson debugged a crash-tastic patch to initialize the C++ side of Firefox for Android sooner, and seems to have fixed the crashiness that plagued such approaches before. Starting the initialization of Gecko itself sooner is important because that can happen in parallel with the work happening in Java on multi-core devices. And chatting with Sriram Ramasubramanian yesterday about some menu initialization that was showing up on profiles, he assured me that startup time was definitely being taken into account when adding new features, which is great!
Before I get to the other work that’s been going on, I need to talk about how cross-language communication works in Firefox for Android.
Firefox for Android uses three primary languages: C++ for Gecko, Java for the Android UI and related bits, and JavaScript for all sorts of things. Java and C++ play nicely via JNI, and Javascript and C++ talk to each other via XPCOM. But what happens when Java needs to talk to JS or vice versa? The solution that’s been chosen here is that Java constructs and serializes a JSON message, sends that to C++, which then notifies observers that a particular kind of message has been received. Registered JavaScript observers (you could also do this in C++, of course, but it’s just easier to do it in JavaScript) are then invoked, parse the JSON, and do their thing. And of course there’s a reverse path for sending things from JavaScript to Java.
With that being said, you might not be surprised that Chris Kitching identified that JSON parsing and serialization are slowing down startup. We spend nearly 200ms doing JSON operations on a Galaxy Nexus–just in Java, never mind JavaScript (though the JavaScript JSON bits are quite fast because they’re backed by C++ code). Part of this is because the interface that Android uses for JSON is not well-designed and part of this is because the implementation could be improved (though Android does not use the json.org implementation, both could be improved). Part of this is also because we do things like JSON-wrap single integers when there are much more efficient ways to communicate such values. I’ve been fixing up some small hotspots (warmspots?), starting with sending telemetry information and Java’s requests for preferences information.
For some things, however, we do have to deal with JSON. Firefox for Android twiddles with the sessionstore information before forwarding it to JavaScript, and sending the sessionstore information in any other format than JSON would be…tedious. The twiddling itself is not particularly expensive, but the reading/parsing/serialization required around it is. For a smallish session of six tabs, where we only have ~2KB of sessionstore JSON to deal with, reading/parsing/serializing the data takes almost 250ms on a Galaxy Nexus. This is expensive enough that techniques like parsing it on a background thread might be worthwhile. It’s not entirely clear whether it helps (different profiling tools say different things, single-core devices may not benefit from it, etc.), though.
I say this without any knowledge about the complexity of Gecko’s parser, but would porting the C++ version to Java be at all feasible?
I reply with an equal amount of ignorance ;), but I’m guessing that would be overkill. Importing a more performant JSON implementation would be an easier possibility (I hear GSON is supposed to be quite good).
The Gecko HTML parser is ALREADY in Java. It’s the Java reference implementation of the HTML 5 parser, compiled by GWT into C++ for embedding in Gecko.
I don’t know if it buys you anything, but yeah, you can have the parser in Java right here, right now.
http://about.validator.nu/htmlparser/
I’m an idiot – you meant the JSON parser, not the HTML parser. I stand corrected.
Could you try to build the json output incrementally in a case like session restore? Or even stream the content as you build it?