up
This commit is contained in:
parent
649ad4b05e
commit
acee6949c9
7 changed files with 35 additions and 35 deletions
|
@ -189,13 +189,11 @@ JavaScript engines apply many optimizations to make it run faster and not affect
|
|||
|
||||
Some of the optimizations:
|
||||
|
||||
- **Generational collection** -- objects are split into two sets: "new ones" and "old ones". Many objects appear, then do their job and die fast, so they can be cleaned up aggressively. Those that survive for long enough, become "old".
|
||||
- **Incremental collection** -- if there are many objects, and we try to walk and mark the whole object set at once, it may take some time and introduce visible delays in the execution. So the engine tries to split the job into pieces. Then pieces are executed one at a time. That requires some extra bookkeeping between them to track changes.
|
||||
- **Generational collection** -- objects are split into two sets: "new ones" and "old ones". Many objects appear, do their job and die fast, they can be cleaned up aggressively. Those that survive for long enough, become "old" and are examined less often.
|
||||
- **Incremental collection** -- if there are many objects, and we try to walk and mark the whole object set at once, it may take some time and introduce visible delays in the execution. So the engine tries to split the garbage collection into pieces. Then the pieces are executed one by one, separately. That requires some extra bookkeeping between them to track changes, but we have many tiny delays instead of a big one.
|
||||
- **Idle-time collection** -- the garbage collector tries to run only while the CPU is idle, to reduce the possible effect on the execution.
|
||||
|
||||
There are other optimizations and flavours of garbage collection algorithms. As much as I'd like to describe them here, I have to hold off, because different engines implement different tweaks and techniques.
|
||||
|
||||
And -- what's even more important, things change as engines develop, so going really deep "in advance", without a real need is probably not worth that. Unless, of course, it is a matter of pure interest, then there will be some links for you below.
|
||||
There are other optimizations and flavours of garbage collection algorithms. As much as I'd like to describe them here, I have to hold off, because different engines implement different tweaks and techniques. And -- what's even more important, things change as engines develop, so going deeper "in advance", without a real need is probably not worth that. Unless, of course, it is a matter of pure interest, then there will be some links for you below.
|
||||
|
||||
## Summary
|
||||
|
||||
|
@ -209,8 +207,8 @@ Modern engines implement advanced algorithms of garbage collection.
|
|||
|
||||
A general book "The Garbage Collection Handbook: The Art of Automatic Memory Management" (R. Jones at al) covers some of them.
|
||||
|
||||
If you are familiar with low-level programming, the more detailed information about V8 garbage collector is in the article [A tour of V8: Garbage Collection](http://jayconrod.com/posts/55/a-tour-of-v8-garbage-collection).
|
||||
If you are familiar with low-level programming, the more detailed information about V8 garbage collector is in the article [A tour of V8: Garbage Collection](http://jayconrod.com/posts/55/a-tour-of-v8-garbage-collection).
|
||||
|
||||
[V8 blog](http://v8project.blogspot.com/) also publishes articles about changes in memory management from time to time. Naturally, to learn the garbage collection, you'd better prepare by learning about V8 internals in general and read the blog of [Vyacheslav Egorov](http://mrale.ph) who worked as one of V8 engineers. I'm saying: "V8", because it is best covered with articles in the internet. For other engines, many approaches are similar, but garbage collection differs in many aspects.
|
||||
[V8 blog](http://v8project.blogspot.com/) also publishes articles about changes in memory management from time to time. Naturally, to learn the garbage collection, you'd better prepare by learning about V8 internals in general and read the blog of [Vyacheslav Egorov](http://mrale.ph) who worked as one of V8 engineers. I'm saying: "V8", because it is best covered with articles in the internet. For other engines, many approaches are similar, but garbage collection differs in many aspects.
|
||||
|
||||
In-depth knowledge of engines is good when you need low-level optimizations. It would be wise to plan that as the next step after you're familiar with the language.
|
||||
|
|
|
@ -159,14 +159,14 @@ alert( clone[id] ); // 123
|
|||
There's no paradox here. That's by design. The idea is that when we clone an object or merge objects, we usually want *all* properties to be copied (including symbols like `id`).
|
||||
|
||||
````smart header="Property keys of other types are coerced to strings"
|
||||
We can only use strings or symbols as keys in objects. Other types are coerced to strings.
|
||||
We can only use strings or symbols as keys in objects. Other types are converted to strings.
|
||||
|
||||
For instance:
|
||||
For instance, a number `0` becomes a string `"0"` when used as a property key:
|
||||
|
||||
```js run
|
||||
let obj = {
|
||||
0: "test" // same as "0": "test"
|
||||
}
|
||||
};
|
||||
|
||||
// both alerts access the same property (the number 0 is converted to string "0")
|
||||
alert( obj["0"] ); // test
|
||||
|
@ -176,11 +176,11 @@ alert( obj[0] ); // test (same property)
|
|||
|
||||
## Global symbols
|
||||
|
||||
Normally, all symbols are different. But sometimes we want same-named symbols to be the same.
|
||||
As we've seen, usually all symbols are different, even if they have the same name. But sometimes we want same-named symbols to be same entities.
|
||||
|
||||
For instance, different parts of our application want to access symbol `"id"` meaning exactly the same property.
|
||||
|
||||
To achieve that, there exists a *global symbol registry*. We can create symbols in it and and access them later, and it guarantees that repeated accesses by the same name return exactly the same symbol.
|
||||
To achieve that, there exists a *global symbol registry*. We can create symbols in it and access them later, and it guarantees that repeated accesses by the same name return exactly the same symbol.
|
||||
|
||||
In order to create or read a symbol in the registry, use `Symbol.for(name)`.
|
||||
|
||||
|
@ -230,7 +230,9 @@ alert( Symbol.keyFor(Symbol.for("name")) ); // name, global symbol
|
|||
alert( Symbol.keyFor(Symbol("name2")) ); // undefined, non-global symbol
|
||||
```
|
||||
|
||||
For non-global symbols, the name is only used for debugging purposes.
|
||||
So, for global symbols the name may be indeed helpful, as we can get a symbol by id.
|
||||
|
||||
And for non-global symbols the name is only used for debugging purposes, like printing out a symbol.
|
||||
|
||||
## System symbols
|
||||
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue