Updated Myth: µBlock consumes over 80MB (markdown)

2014-08-22 08:21:55 -07:00 · 2014-08-22 08:21:55 -07:00 · b940778fb6
parent 3896ee0d37
commit b940778fb6
1 changed files with 1 additions and 1 deletions
--- a/Myth:-µBlock-consumes-over-80MB.md
+++ b/Myth:-µBlock-consumes-over-80MB.md
@ -15,4 +15,4 @@ The top image shows the memory footprint of µBlock right after launch (Chrome 6
 Note that µBlock's baseline memory footprint won't change that much afterwards. It will likely settles a few MB above the memory footprint reached after garbage collection has occurred, whenever the garbage collector is permitted to do its job.
-When repeatedly reload all filters (after say, changing selection of filter lists), I notice µBlock's baseline memory footprint edges higher each time. I entered [an issue](https://github.com/gorhill/uBlock/issues/22) to be remembered to investigate whether anything can be done for this. Currently I think this is simply caused by cumulative memory fragmentation and there might be nothing which can be done. Typically I expected users whill select a set of lists and stick to that afterward, so this would make this particular issue irrelevant.
+When repeatedly reload all filters (after say, changing selection of filter lists), I notice µBlock's baseline memory footprint edges higher each time. I entered [an issue](https://github.com/gorhill/uBlock/issues/22) to be remembered to investigate whether anything can be done for this. Currently I think this is simply caused by cumulative memory fragmentation and there might be nothing which can be done. Typically I expect users will select a set of lists and stick to that afterward, so this would make this particular issue irrelevant.
`@ -15,4 +15,4 @@ The top image shows the memory footprint of µBlock right after launch (Chrome 6`

	`Note that µBlock's baseline memory footprint won't change that much afterwards. It will likely settles a few MB above the memory footprint reached after garbage collection has occurred, whenever the garbage collector is permitted to do its job.`	`Note that µBlock's baseline memory footprint won't change that much afterwards. It will likely settles a few MB above the memory footprint reached after garbage collection has occurred, whenever the garbage collector is permitted to do its job.`

	When repeatedly reload all filters (after say, changing selection of filter lists), I notice µBlock's baseline memory footprint edges higher each time. I entered [an issue](https://github.com/gorhill/uBlock/issues/22) to be remembered to investigate whether anything can be done for this. Currently I think this is simply caused by cumulative memory fragmentation and there might be nothing which can be done. Typically I expected users whill select a set of lists and stick to that afterward, so this would make this particular issue irrelevant.	When repeatedly reload all filters (after say, changing selection of filter lists), I notice µBlock's baseline memory footprint edges higher each time. I entered [an issue](https://github.com/gorhill/uBlock/issues/22) to be remembered to investigate whether anything can be done for this. Currently I think this is simply caused by cumulative memory fragmentation and there might be nothing which can be done. Typically I expect users will select a set of lists and stick to that afterward, so this would make this particular issue irrelevant.