Done! https://github.com/servo/servo/issues/11888
Thanks for the suggestion. Best, Shing - Shing Lyu | Mozilla Taipei 2016-06-28 3:56 GMT+08:00 Jet Villegas <jville...@mozilla.com>: > I see that Servo was replacing an iterating strcmp with hashing, so that > explains the speed wins they're seeing. Maybe they should look into bsearch > for the memory wins too, if speed is comparable. > > Shing Lyu: will you note that in the Servo github issue? > > Thanks, > > --Jet > > > On Mon, Jun 27, 2016 at 11:15 AM, Nathan Froyd <nfr...@mozilla.com> wrote: > >> On Mon, Jun 27, 2016 at 2:01 PM, Jet Villegas <jville...@mozilla.com> >> wrote: >> > Shing Lyu from our Taipei Layout team reports a 25% page load >> improvement >> > in Servo from moving to a hashtable lookup from an iterator search of >> the >> > public suffix list ( https://publicsuffix.org/ ) >> > >> > Should Gecko do the same thing and replace our binary search method? >> > >> https://dxr.mozilla.org/mozilla-central/source/security/manager/ssl/nsSiteSecurityService.cpp#917 >> >> Gecko's public suffix code lives over in netwerk/dns/: >> >> >> https://hg.mozilla.org/mozilla-central/file/tip/netwerk/dns/nsEffectiveTLDService.cpp#l51 >> >> Bug 1247835 [1] changed its hashtable usage to a binary search earlier >> this year and we have not noticed any negative fallout. Performance >> measurements in the bug suggest the binary search might actually be >> slightly faster, and the current structure enables us to easily share >> the lookup structures between processes, as well as being smaller than >> the previous hashtable scheme. (If we switched to downloading public >> suffix lists--bug 1083971 [2]--the sharing would presumably go away, >> but we'd still get the size wins.) >> >> -Nathan >> >> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1247835 >> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1083971 >> > > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
