-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optimize memory usage of hosts filters #714
Comments
Just a quick Update & a Question. Its not just large filter lists but when the yaml gets large as it has: BLOCKLIST (Entries added here from gui block command) REGEX WHITELIST It be better if GUI had three sections (one for each) and saved in files rather than yaml. In the meantime I assume that as Filters and hosts blocklists supports basic adblock rules and hosts files syntax that I could copy the entries from YAML, put them into files and add to Filters and hosts |
Since we are on topic of host files, would also be nice if you can add host aliases like in normal host files ex: I have many local resources that have different names. Thank you all again :) |
@skynet01 |
nice, is this already live? If yes how do we use it. |
@skynet01 not yet ready, but it will be soon |
* commit '096a95998749b673bc9be638bc9c8f6f0d13be41': * dnsforward: use new dnsfilter interface * dnsfilter: adapt tests to new interface * dnsfilter: use urlfilter package * dnsfilter: remove code for filtering rules * dns: rename dnsfilter.Filter.Rule -> dnsfilter.Filter.Data * dnsforward: use separate ServerConfig object * use urlfilter
by default AdGuard Simplified Domain Names filter enable its use around 20mb |
No, I am pretty sure this library has nothing to do with memory usage optimization. The memory footprint of the AdGuard SDN at the moment is about 5-8MB, and for hosts-file based filter lists it's even less. The problem is that golang's GC is pretty greedy and if there's memory available, it prefers not to free it. You can try adding |
It seems (#713 #712) people tend to load REALLY HUGE hosts lists, and with our current approach of keeping everything in memory, it leads to serious memory usage.
Here's what I suggest:
I think there are some existing libraries using more or less the same approach.
Useful libraries:
The text was updated successfully, but these errors were encountered: