From cffcd98bee33be7d84cc93464871579f9e7b42fc Mon Sep 17 00:00:00 2001 From: gorhill Date: Tue, 9 Sep 2014 09:41:24 -0700 Subject: [PATCH] Updated Notes on memory benchmarks, selfies (markdown) --- ...arks, selfies.md => Notes-on-memory-benchmarks,-selfies.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) rename Notes on memory benchmarks, selfies.md => Notes-on-memory-benchmarks,-selfies.md (91%) diff --git a/Notes on memory benchmarks, selfies.md b/Notes-on-memory-benchmarks,-selfies.md similarity index 91% rename from Notes on memory benchmarks, selfies.md rename to Notes-on-memory-benchmarks,-selfies.md index 14abf7c..63be59e 100644 --- a/Notes on memory benchmarks, selfies.md +++ b/Notes-on-memory-benchmarks,-selfies.md @@ -4,7 +4,9 @@ I already wrote about this [here](https://github.com/gorhill/uBlock/wiki/Myth:-% 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. -However there are specific operations which will cause µBlock to churn through lot of short-term memory (let's call this "memory-churning"), and although all that short-term memory is freed by µBlock once the specific operation is completed, not all that freed memory will be garbage-collected by the browser for whatever reasons. Memory fragmentation is possibly a factor. Memory-churning operations lead to an higher memory baseline for µBlock, as can be seen in the browser's _Task Manager_. +However there are specific operations which will cause µBlock to churn through lot of short-term memory (let's call this "memory-churning"), and although all that short-term memory is freed by µBlock once the specific operation is completed, not all that freed memory will be garbage-collected by the browser for whatever reasons. Memory fragmentation is possibly a factor. + +Memory-churning operations lead to an higher permanent memory baseline for µBlock, as can be seen in the browser's _Task Manager_. So in essence you won't obtain the same memory figures which I used in my published benchmarks if you caused µBlock to go through memory-churning before looking at the memory figures.