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
