From 6688eb2ccac98091ffa88d8f00ac54fde8fcf914 Mon Sep 17 00:00:00 2001 From: gorhill Date: Thu, 5 Feb 2015 08:45:29 -0500 Subject: [PATCH] comments to better document code --- src/js/static-net-filtering.js | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/src/js/static-net-filtering.js b/src/js/static-net-filtering.js index 1e730ecd6..4439187e9 100644 --- a/src/js/static-net-filtering.js +++ b/src/js/static-net-filtering.js @@ -877,6 +877,15 @@ FilterRegexHostname.fromSelfie = function(s) { /******************************************************************************/ // Dictionary of hostnames +// +// FilterHostnameDict is the main reason why uBlock is not equipped to keep +// track of which filter comes from which list, and also why it's not equipped +// to be able to disable a specific filter -- other than through using a +// counter-filter. +// +// On the other hand it is also *one* of the reason uBlock's memory and CPU +// footprint is smaller. Compacting huge list of hostnames into single strings +// saves a lot of memory compared to having one dictionary entry per hostname. var FilterHostnameDict = function() { this.h = ''; // short-lived register @@ -913,7 +922,14 @@ FilterHostnameDict.prototype.meltBucket = function(len, bucket) { return map; }; -// How the key is derived dictates the number and size of buckets. +// How the key is derived dictates the number and size of buckets: +// - more bits = more buckets = higher memory footprint +// - less bits = less buckets = lower memory footprint +// - binary search mitigates very well the fact that some buckets may grow +// large when fewer bits are used (or when a large number of items are +// stored). Binary search also mitigate to the point of non-issue the +// CPU footprint requirement with large buckets, as far as reference +// benchmark shows. // // A hash key capable of better spread while being as fast would be // just great.