Places Performance
This week I’ve been working on putting together a small document about the performance of places (versus the older mork backend) , and taking a stab at collecting some data as well.
So far the document looks like this. The numbers I got for pageload are from mozilla/tools/performance, but with a different page set (which I can’t give out due to copyright restrictions).
The tests look pretty promising so far. The trend appears to be: places is a little slower when there’s none or very little history data, but is faster and faster the more history there is. And this makes intuitive sense to me, after all we’re using an indexed database which is optimized for these kinds of things.
Still, we have a lot of work ahead of us to pin down all the problem areas, and keep them under control. This is just the beginning.
October 18th, 2006 at 5:23 am
As far as I am concerned, Places’ biggest problem has been its UI and usability. I don’t know how users perceive it on other platforms, but on Mac it feels totally out of place and un-standard.
(You click a button, a weird floating window appears, effectively de-focusing the main browser window. It has a button with “>>” as title. I’ve never ever seen such a creature in another mac app, though I vaguely can see what it’s trying to resemble, and that is not when you’ve actually brought up the actual main search window in Places).
I’m sure the backend architecture makes good sense, but the actual interface will need some rethinking to be successful, in my opinion.
/Håkan
October 18th, 2006 at 1:27 pm
Why not to use flat files up to a certain number (2 x statistical number where performance is the same, for example) of history and bookmark entires and switch to database after that. Some users often delete their history.
October 24th, 2006 at 12:38 pm
Håkan,
I agree with you in general. That’s why our first task (for the places team) is to get the Firefox 2 UI to work on top of the places backend. Which doesn’t mean that we’ll be stuck there, we’d just prefer to use that as a starting point.
Vi,
Perhaps, but we’d need to know what the gains are for that, since it would require keeping around a bunch of extra code for dealing with both backend formats, and for converting between the two. There would also be a small performance hit at some point when the conversion kicks in.
This is why we need the performance data, so we can evaluate how much faster/slower each option is. My gut feeling right now (based on the tests I ran last week) is that we’ll be OK without resorting to using two formats based on history size.