Closed Bug 103745 Opened 23 years ago Closed 13 years ago

evaluate performance of mozilla cookies implementation

Categories

(Core :: Networking: HTTP, defect, P3)

defect

Tracking

()

RESOLVED FIXED

People

(Reporter: darin.moz, Unassigned)

References

Details

(Keywords: perf)

evaluate performance of mozilla cookies implementation. in particular, i'd like to determine how expensive it is to be calling into the cookie manager for every http request/response.
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla0.9.6
here's some results using a linux commercial build from 2001/10/01: [with libcookie.so] Test id: 3BC15AD47D Avg. Median : 1060 msec Minimum : 252 msec Average : 1092 msec Maximum : 3812 msec http://cowtools.mcom.com/page-loader/graph.pl?id=3BC15AD47D [without libcookie.so] Test id: 3BC15CFDD8 Avg. Median : 1027 msec Minimum : 247 msec Average : 1051 msec Maximum : 3826 msec http://cowtools.mcom.com/page-loader/graph.pl?id=3BC15CFDD8 this amounts to a 3% performance difference, and i think it means that we should not be sending notifications to the cookie manager unless we actually have cookies to report. see bug 96178 for existing plans to make this possible.
Keywords: perf
Blocks: 95314
Target Milestone: mozilla0.9.6 → mozilla0.9.7
morse: this bug might interest you.
something along the lines of bug 96178 might help.
-> 0.9.8 (perhaps even later)
Target Milestone: mozilla0.9.7 → mozilla0.9.8
unlikely to get around to doing anything about this in the mozilla1.0 timeframe. -> future
Target Milestone: mozilla0.9.8 → Future
Is this bug still relevent now that the cookie code is being rewritten?
sort of.. this is more of a meta bug than anything else. the point of this bug was to determine why the presence of the cookie DLL was so costly. we may or may not have addressed all of that with the cookie rewrite. i doubt it since we didn't see much of any change in Tp with the current cookie changes :-/
ah, thx for cc'ing me darin. "cookies" and "performance" do not go in the same sentence, unless there's a strong negation present. the rewrite has not done anything to address performance yet (apart from micro optimizations and other fun stuff). the perf improvements will be coming up shortly. phase 3 sets the stage for this, and I may introduce arenas there (they're so easy) so that'll give us some malloc bloat + perf wins. the really big win will come when a) we move to hashes (phase 4, dare i mention 1.4b in this sentence? ;) darin: i've actually just finished coding up the hash conversion. so do let me know if there's a chance of it being on the radar for 1.4b, and i'll push it through ASAP. not sure on this one because although it's a conceptually simple change, it is a big patch and i'm not sure what your take will be for 1.4b. b) we integrate cookies into necko and kill that infernal nsCookieHTTPNotify.
dwitte: any update?
QA Contact: tever → benc
Assignee: darin → nobody
Status: ASSIGNED → NEW
QA Contact: benc → networking.http
Target Milestone: Future → ---
Should this bug still be opened?
Nope. Cookies are fast now!
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.