Last Comment Bug 103745 - evaluate performance of mozilla cookies implementation
: evaluate performance of mozilla cookies implementation
: perf
Product: Core
Classification: Components
Component: Networking: HTTP (show other bugs)
: Trunk
: All All
P3 normal with 2 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Patrick McManus [:mcmanus]
Depends on:
Blocks: 95314
  Show dependency treegraph
Reported: 2001-10-08 15:25 PDT by Darin Fisher
Modified: 2014-04-26 03:08 PDT (History)
14 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image Darin Fisher 2001-10-08 15:25:15 PDT
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.
Comment 1 User image Darin Fisher 2001-10-08 16:27:16 PDT
here's some results using a linux commercial build from 2001/10/01:

Test id: 3BC15AD47D
Avg. Median : 1060 msec     Minimum     : 252 msec
Average     : 1092 msec     Maximum     : 3812 msec

Test id: 3BC15CFDD8
Avg. Median : 1027 msec     Minimum     : 247 msec
Average     : 1051 msec     Maximum     : 3826 msec

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.
Comment 2 User image Darin Fisher 2001-10-26 14:58:10 PDT
morse: this bug might interest you.
Comment 3 User image Darin Fisher 2001-10-26 15:00:10 PDT
something along the lines of bug 96178 might help.
Comment 4 User image Darin Fisher 2001-11-08 15:49:51 PST
-> 0.9.8 (perhaps even later)
Comment 5 User image Darin Fisher 2001-12-18 12:24:40 PST
unlikely to get around to doing anything about this in the mozilla1.0 timeframe.

-> future
Comment 6 User image Andrew Taylor 2003-04-07 15:51:42 PDT
Is this bug still relevent now that the cookie code is being rewritten?
Comment 7 User image Darin Fisher 2003-04-07 18:37:14 PDT
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 :-/
Comment 8 User image 2003-04-07 18:47:32 PDT
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.
Comment 9 User image benc 2004-09-02 07:02:15 PDT
dwitte: any update?
Comment 10 User image Marco Castelluccio [:marco] 2011-07-22 11:55:24 PDT
Should this bug still be opened?
Comment 11 User image 2011-07-22 12:02:01 PDT
Nope. Cookies are fast now!

Note You need to log in before you can comment on or make changes to this bug.