As most of you probably know, starting with Diablo, the MicroB web browser comes in two different components:

* The UI part of the browser that starts when you click on a bookmark.
* The resident part of the browser, aka browserd that is always running, as long as your tablet is on, and handles most of the actual browsing tasks.

The purpose of the split, according to Nokia engineers, has been to shorten browser startup time. The downside is 5-6MB of lost memory (when not using the browser) and the fact that once some web page makes browserd hang eating 100% CPU cycles, it is very difficult to kill it using stock tablet software.

But the real win is the browser startup time, right? Well, not quite so. I have done some testing and found that it takes ~18 seconds to start MicroB and load an arbitrary page with browserd and ~21 seconds without browserd. This is the stunning difference of 3 seconds or 14.3%!

Some may say that it is not fair to include web page loading time. Specially for these people, I measured time from clicking on a bookmark to the moment the word "Connecting" appears in the browser status line. This resulted in ~15 seconds with browserd and ~18 seconds without browserd. Same 3 second difference or 16.7%.

In other words, browserd appears to be useless in terms of startup time reduction. Unfortunately, Nokia folks are refusing to accept this idea at the moment. Therefore, I suggest that we all take load time measurements, file an official bug, and make Nokia either disable browserd or fix it so that it gives real benefit.

You can help by following instructions below and posting results to this thread. How to test:

1. Use CPU Load applet to verify you have two copies of browserd running. One should take ~2MB, another will take 11-19MB.
2. Start MicroB by clicking on some bookmark and measure time from the click to the moment you see the "Connecting" message.
3. Quit MicroB and use CPU Load applet to kill the bigger copy of browserd.
4. Repeat step #2, measure time, and post both times to this thread.

If you would like to measure the total time (including page loading and rendering), make sure you include the URL of a page you were loading. It may also be good to mention which MicroB extensins you are running.

However browserd function is not only related to startup time. Browserd is managing the browsing windows and when one of them crash, it doesn't bring down all of them. That's a minor plus at least

As far as I could understand, browsing windows are now no more than thin clients to browserd where actually work occurs. Thus, if something is going to crash while you are browsing, it will be browserd itself. And once it goes into cardiac arrest (as it often does when it chokes on some CSS or JS code), killing it is more difficult than just closing a window.

You're probably right, i also don't like the way it is handled now. However instead of just complaining, can't we think of a better way to manage the browsing sessions (if we can't then we can always go back to just complaining )?

Personally, I do not think session management is going to help reducing MicroB startup time but if you are really into session management, I would suggest keeping a single DBus server in the system that takes URLs, loads, caches them, and returns local filenames ot the caller. Such a server will be really small and simple. Rendering will still occur inside MicroB app.

As to reducing startup times, a good idea would be to reduce library dependencies and config file complexity. For example, bookmarks are currently stored in an XML file. Storing them as plain text or maybe as gconf entries (whatever is faster) will save you on XML parsing and possibly remove the dependence on XML parser completely. Not being familiar with MicroB internals, I can't say for sure though.

gconf FTW. Currently, browser history is stored in a plain txt file and when you have been on a lot of sites, the time MicroB takes to load up the history list really shows.

EDIT: Then again if the startup time is not affected much, wouldn't it be better if the browserd stays, but is started along with the first browser window and stopped maybe a minute after the last is closed? Kinda like the way Canola is stopping its daemons.

After all besides the memory loss, the Diablo browser fares kinda better than the chinook one. An upstream core refresh would probably help too.

You can't remove xml dependency in a browser Then again the gecko engine uses its own.

I like the way FF3 handles various storages - sqlite3. Simple, fast and powerful.

Yes, this is what I have suggested to timeless. My other suggestion was to kill browserd if nobody uses it for 15 minutes or so. Neither suggestion has been seriously considered, unfortunately.

Actually, I see more busy loop hangups with Diablo browser. LiveJournal.com has become almost unusable.

look like at netscape navigator 2 ... it doesn't require xml !