actually after we have created nodes if we are in a tree where tags column is required (library, but in future could be added to sidebar too), we query for tags apart. So after we built 10 000 nodes, we fire 10000 queries to get tags, we could instead directly get tags with a subquery (like the awesomebar) and pass them to the node constructor, then simply maintain them updated when needed (tagAdded, tagRemoved observer notifications?)

The query is called a lot especially in searches and in trees, but searches is where this really hurts us. Also GetTags should not even try to get tags for non bookmarks.

Trying changing queries i discovered this could potentially hurt our queries till 130ms (with a relatively large db with lot of tags) this would be faster: 1. during Sidebar/Library searches 2. in views that show the Tags column (actually only the Library, could be more in future) 3. in future when we will be able to observe a single item node. but actually will hurt us: 1. in all uri queries that do not search 2. in all views that don't show tags (menu, toolbar). But we can know how we will use nodes in future (we could show them in bookmark tooltips for example), nor we do know how extensions are using our nodes. This would not be the case with externally stored tags (eg in a separate table) since such a table would probably have an index on tag name, and avoid joining bookmarks table with itself. But since we don't have that yet, we have to make a choice. We could optimize the search case, and leave the other ones untouched till tags will be more performant, or simply go on and accept a small loss in uri queries. Since the latter would probably move some query from <100ms to >100ms, and we want responsiveness, i'll probably try the former.

i'm splitting to a new bug, this should still be done once tags have their own table, we simply can't do this right now.

continuing on bug 500391.

I have done this some time ago elsewhere