Merge pull request iliakan#198 from bogem/clearer

iliakan · iliakan · commit 724cac574528 · 2015-11-30T23:00:33.000+03:00
Make statement clearer
diff --git a/1-js/5-functions-closures/6-memory-management/article.md b/1-js/5-functions-closures/6-memory-management/article.md
@@ -17,7 +17,7 @@
 </ul>
 
 Эти значения гарантированно хранятся в памяти. Мы будем называть их *корнями*.
-</li> 
+</li>
 <li>**Любое другое значение сохраняется в памяти лишь до тех пор, пока доступно из корня по ссылке или цепочке ссылок.**</li>
 </ol>
 
@@ -31,7 +31,7 @@
 
 ### Достижимость и наличие ссылок
 
-Есть одно упрощение для работы с памятью: "значение остаётся в памяти, пока на него есть ссылка". 
+Есть одно упрощение для работы с памятью: "значение остаётся в памяти, пока на него есть хотя бы одна ссылка".
 
 Но такое упрощение будет верным лишь в одну сторону.
 
@@ -47,7 +47,7 @@ var user = {
 user = null;
 ```
 
-Теперь объект `{ name: "Вася" }` более недоступен. Память будет освобождена. 
+Теперь объект `{ name: "Вася" }` более недоступен. Память будет освобождена.
 </li>
 <li>**Неверно -- в другую сторону: наличие ссылки не гарантирует, что значение останется в памяти.**
 
@@ -62,9 +62,9 @@ petya.friend = vasya;
 vasya = petya = null;
 ```
 
-Несмотря на то, что на объекты `vasya`, `petya` ссылаются друг на друга через ссылку `friend`, то есть можно сказать, что на каждый из них есть ссылка, последняя строка делает эти объекты в совокупности недостижимыми. 
+Несмотря на то, что на объекты `vasya`, `petya` ссылаются друг на друга через ссылку `friend`, то есть можно сказать, что на каждый из них есть ссылка, последняя строка делает эти объекты в совокупности недостижимыми.
 
-Поэтому они будут удалены из памяти. 
+Поэтому они будут удалены из памяти.
 
 Здесь как раз и играет роль "достижимость" -- оба этих объекта становятся недостижимы из корней, в первую очередь, из глобальной области, стека.
 
@@ -138,7 +138,7 @@ window.family = null;
 Как видим, объекты в конструкции всё ещё связаны между собой. Однако, поиск от корня их не находит, они не достижимы, и значит сборщик мусора удалит их из памяти.
 
 [smart header="Оптимизации"]
-Проблема описанного алгоритма -- в больших задержках. Если объектов много, то на поиск всех достижимых  уйдёт довольно много времени. А ведь выполнение скрипта при этом должно быть остановлено, уже просканированные объекты не должны поменяться до окончания процесса. Получатся небольшие, но неприятные паузы-зависания в работе скрипта. 
+Проблема описанного алгоритма -- в больших задержках. Если объектов много, то на поиск всех достижимых  уйдёт довольно много времени. А ведь выполнение скрипта при этом должно быть остановлено, уже просканированные объекты не должны поменяться до окончания процесса. Получатся небольшие, но неприятные паузы-зависания в работе скрипта.
 
 Поэтому современные интерпретаторы применяют различные оптимизации.
 
@@ -157,7 +157,7 @@ function showTime() {
 
 ## Замыкания
 
-Объекты переменных, о которых шла речь ранее, в главе про замыкания, также подвержены сборке мусора. Они следуют тем же правилам, что и обычные объекты. 
+Объекты переменных, о которых шла речь ранее, в главе про замыкания, также подвержены сборке мусора. Они следуют тем же правилам, что и обычные объекты.
 
 Объект переменных внешней функции существует в памяти до тех пор, пока существует хоть одна внутренняя функция, ссылающаяся на него через свойство `[[Scope]]`.
 
@@ -206,7 +206,7 @@ function f() {
   return function() {};
 }
 
-// 3 функции, каждая ссылается на свой объект переменных, 
+// 3 функции, каждая ссылается на свой объект переменных,
 // каждый со своим значением value
 var arr = [f(), f(), f()];
 ```
@@ -224,15 +224,15 @@ function f() {
 }
 
 var g = f(); // функция g жива
-// а значит в памяти остается соответствующий объект переменных f() 
+// а значит в памяти остается соответствующий объект переменных f()
 
 g = null; // ..а вот теперь память будет очищена
 ```
 
 </li>
 </ul>
 
-### Оптимизация в V8 и её последствия 
+### Оптимизация в V8 и её последствия
 
 Современные JS-движки делают оптимизации замыканий по памяти. Они анализируют использование переменных и в случае, когда переменная из замыкания абсолютно точно не используется, удаляют её.
 
@@ -286,7 +286,7 @@ g();
 Это не глюк отладчика, а особенность работы V8, которая, возможно, будет когда-нибудь изменена. Вы всегда сможете проверить, не изменилось ли чего, запустив примеры на этой странице.
 [/warn]
 
-## Влияние управления памятью на скорость 
+## Влияние управления памятью на скорость
 
 На создание новых объектов и их удаление тратится время. Это важно иметь в виду в случае, когда важна производительность.
 
@@ -319,8 +319,8 @@ timeRecursion = performance.now() - timeRecursion;
 alert( "Разница в " + (timeRecursion / timeLoop) + " раз" );
 ```
 
-Различие в скорости на таком примере может составлять, в зависимости от интерпретатора, 2-10 раз. 
+Различие в скорости на таком примере может составлять, в зависимости от интерпретатора, 2-10 раз.
 
 Вообще, этот пример -- не показателен. Ещё раз обращаю ваше внимание на то, что такие искусственные "микротесты" часто врут. Правильно их делать -- отдельная наука, которая выходит за рамки этой главы. Но и на практике ускорение в 2-10 раз оптимизацией по количеству объектов (и вообще, любых значений) -- отнюдь не миф, а вполне достижимо.
 
-В реальной жизни в большинстве ситуаций такая оптимизация несущественна, просто потому что "JavaScript и так достаточно быстр". Но она может быть эффективной для "узких мест" кода. 
+В реальной жизни в большинстве ситуаций такая оптимизация несущественна, просто потому что "JavaScript и так достаточно быстр". Но она может быть эффективной для "узких мест" кода.
