From 46f82c06eac08965c8bb8bc11dd52042317508b9 Mon Sep 17 00:00:00 2001 From: gorhill Date: Tue, 9 Sep 2014 09:21:16 -0700 Subject: [PATCH] Updated Notes on memory benchmarks, selfies (markdown) --- ...hmarks, selfies.md => Notes-on-memory-benchmarks,-selfies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename Notes on memory benchmarks, selfies.md => Notes-on-memory-benchmarks,-selfies.md (94%) diff --git a/Notes on memory benchmarks, selfies.md b/Notes-on-memory-benchmarks,-selfies.md similarity index 94% rename from Notes on memory benchmarks, selfies.md rename to Notes-on-memory-benchmarks,-selfies.md index 6f9428e..c10633d 100644 --- a/Notes on memory benchmarks, selfies.md +++ b/Notes-on-memory-benchmarks,-selfies.md @@ -1,4 +1,4 @@ -µBlock is quite memory efficient compared to most other blockers. However, users will often report that this is not the case. I already wrote about this [here](https://github.com/gorhill/uBlock/wiki/Myth:-%C2%B5Block-consumes-over-80MB). I will add more details here, as there is more than garbage collection to factor in. +µBlock is quite memory efficient compared to most other blockers. However, users will often report that this is not the case. I already wrote about this [here](https://github.com/gorhill/uBlock/wiki/Myth:-%C2%B5Block-consumes-over-80MB). I will add more details here, as there is more than just garbage collection to factor in. When I run my benchmarks, the methodology used is to reproduce what I believe is the most common scenario: a user launches his/her browser with µBlock already fully configured to his/her liking, without further changes to the selection of filter lists. The launch-and-forget scenario. I also benchmark this way for all other blockers.