Closed
Bug 492799
Opened 16 years ago
Closed 16 years ago
nodeIsReadOnly should cache read-only item ids
Categories
(Firefox :: Bookmarks & History, defect)
Firefox
Bookmarks & History
Tracking
()
RESOLVED
FIXED
Firefox 3.6a1
People
(Reporter: dietrich, Assigned: dietrich)
Details
(Keywords: perf, Whiteboard: [TSnappiness])
Attachments
(1 file, 3 obsolete files)
4.17 KB,
patch
|
mak
:
review+
|
Details | Diff | Splinter Review |
need to remove the observer at shutdown
Assignee | ||
Updated•16 years ago
|
Whiteboard: [TSnappiness]
Assignee | ||
Comment 1•16 years ago
|
||
ugh. anti-leak crap.
Attachment #377210 -
Attachment is obsolete: true
Attachment #377301 -
Flags: review?(mak77)
Comment 2•16 years ago
|
||
Comment on attachment 377301 [details] [diff] [review]
v1
> nodeIsReadOnly: function PU_nodeIsReadOnly(aNode) {
>- if (this.nodeIsFolder(aNode) || this.nodeIsDynamicContainer(aNode))
>- return this.bookmarks.getFolderReadonly(this.getConcreteItemId(aNode));
>- if (this.nodeIsQuery(aNode) &&
>+ if (aNode.itemId != -1) {
>+ if (this._readOnly.indexOf(aNode.itemId) != -1)
>+ return true;
>+ }
>+ else if (this.nodeIsQuery(aNode) &&
> asQuery(aNode).queryOptions.resultType !=
> Ci.nsINavHistoryQueryOptions.RESULTS_AS_TAG_CONTENTS)
> return aNode.childrenReadOnly;
> return false;
hm, this does not look correct if aNode.itemId != -1, it could also be a bookmark, but we only support setting readonly on folders...
also, if aNode.itemId != -1 includes bookmarked queries, while those should be catched by next check.
Please, ensure this won't end up in the Ts path, adding those observers and getting all annotated items could hurt there.
Attachment #377301 -
Flags: review?(mak77) → review-
Assignee | ||
Comment 3•16 years ago
|
||
fixed. it doesn't appear to be called during startup. however, if it is, it might outweigh the multiple sql calls to nodeIsReadOnly.
Attachment #377301 -
Attachment is obsolete: true
Attachment #377309 -
Flags: review?(mak77)
Comment 4•16 years ago
|
||
Comment on attachment 377309 [details] [diff] [review]
v1.1
>diff --git a/toolkit/components/places/src/utils.js b/toolkit/components/places/src/utils.js
> nodeIsQuery: function PU_nodeIsQuery(aNode) {
> return aNode.type == Ci.nsINavHistoryResultNode.RESULT_TYPE_QUERY;
> },
>
> /**
>+ * Cache of read-only item IDs. Managed by the annotation observer
>+ * below.
>+ */
can you expand the comment a bit explaining how this works really?
>+ // nsIObserver
>+ observe: function PU_observe(aSubject, aTopic, aData) {
>+ if (aTopic == "xpcom-shutdown") {
>+ this.annotations.removeObserver(this);
>+ const os = Cc["@mozilla.org/observer-service;1"].
>+ getService(Ci.nsIObserverService);
>+ os.removeObserver(this, "xpcom-shutdown");
hm, i'm actually thinking if there could be a possibility _readOnly is never called. For example in tests that use PlacesUtils, or in third party implementations.
I can't recall if removeObserver throws if the observer does not exist (iirc annotations will throw), in case those should be catched.
> nodeIsReadOnly: function PU_nodeIsReadOnly(aNode) {
>- if (this.nodeIsFolder(aNode) || this.nodeIsDynamicContainer(aNode))
>- return this.bookmarks.getFolderReadonly(this.getConcreteItemId(aNode));
>- if (this.nodeIsQuery(aNode) &&
>- asQuery(aNode).queryOptions.resultType !=
>- Ci.nsINavHistoryQueryOptions.RESULTS_AS_TAG_CONTENTS)
>+ if (this.nodeIsFolder(aNode)) {
why did you discard nodeIsDynamicContainer check? I think it should come back
ok, looking at the code the calls you see probably come from updateCommands or disallowInsertion, so this should be called on focus the first time... since that appear being out of Ts, r=me
PS: can you guess a number of these annotations checks, just to inderstand how much these queries are called while using the library.
Attachment #377309 -
Flags: review?(mak77) → review+
Assignee | ||
Comment 5•16 years ago
|
||
comments fixed
Attachment #377309 -
Attachment is obsolete: true
Attachment #377527 -
Flags: review?(mak77)
Assignee | ||
Comment 6•16 years ago
|
||
on an empty profile, about 14 calls when the library is loaded, and another 5 each time it's focused.
Comment 7•16 years ago
|
||
(In reply to comment #6)
> on an empty profile, about 14 calls when the library is loaded, and another 5
> each time it's focused.
Is that with or without the patch applied?
Updated•16 years ago
|
Attachment #377527 -
Flags: review?(mak77) → review+
Comment 8•16 years ago
|
||
Comment on attachment 377527 [details] [diff] [review]
v1.2
i expect this is a win because we don't have many read-only items.
Just now i was thinking if we should leave PlacesUtils untouched and instead hack this into PlacesUIUtils being a trick for frontend perf.
But i think it is ok like it is, nobody should have thousands readonly items.
Assignee | ||
Comment 9•16 years ago
|
||
(In reply to comment #7)
> (In reply to comment #6)
> > on an empty profile, about 14 calls when the library is loaded, and another 5
> > each time it's focused.
> Is that with or without the patch applied?
without
(In reply to comment #8)
> (From update of attachment 377527 [details] [diff] [review])
> i expect this is a win because we don't have many read-only items.
exactly. we check all the folder nodes, even tho 99% are not read-only. caching this very small set allows us to fast-path the check.
> Just now i was thinking if we should leave PlacesUtils untouched and instead
> hack this into PlacesUIUtils being a trick for frontend perf.
> But i think it is ok like it is, nobody should have thousands readonly items.
i think it's better in toolkit, along w/ the rest of the nodeIs* checks. also, if Fennec uses utils.js, they'll want these type of optimizations as well.
Assignee | ||
Updated•16 years ago
|
Whiteboard: [TSnappiness] → [TSnappiness][has patch][has review][can land]
Comment 10•16 years ago
|
||
(In reply to comment #9)
> (In reply to comment #7)
> > Is that with or without the patch applied?
> without
And just to be clear, they all go away now with the patch?
Assignee | ||
Comment 11•16 years ago
|
||
(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #7)
> > > Is that with or without the patch applied?
> > without
> And just to be clear, they all go away now with the patch?
now it's 1 query, lazily executed, for the lifetime of the running application.
Comment 12•16 years ago
|
||
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Whiteboard: [TSnappiness][has patch][has review][can land] → [TSnappiness]
Target Milestone: --- → Firefox 3.6a1
You need to log in
before you can comment on or make changes to this bug.
Description
•