Comments on: Places Performance http://blog.mozilla.com/thunder/2006/10/17/places-performance/ Just another blog.mozilla.com weblog Sat, 17 Feb 2007 01:49:50 -0800 http://wordpress.org/?v=2.8.6 hourly 1 By: Dan http://blog.mozilla.com/thunder/2006/10/17/places-performance/comment-page-1/#comment-6 Dan Tue, 24 Oct 2006 19:38:51 +0000 http://blog.mozilla.com/thunder/2006/10/17/places-performance/#comment-6 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. 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.

]]> By: Vi http://blog.mozilla.com/thunder/2006/10/17/places-performance/comment-page-1/#comment-5 Vi Wed, 18 Oct 2006 20:27:58 +0000 http://blog.mozilla.com/thunder/2006/10/17/places-performance/#comment-5 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. 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.

]]> By: Håkan http://blog.mozilla.com/thunder/2006/10/17/places-performance/comment-page-1/#comment-4 Håkan Wed, 18 Oct 2006 12:23:51 +0000 http://blog.mozilla.com/thunder/2006/10/17/places-performance/#comment-4 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 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

]]>