I'll just point this out: low level optimization like that is very unintuitive.
Game engines often use object pools to avoid allocation and GC, since even a single `malloc` is sometimes too expensive. There's other ways of reducing GC as well, such as persistence (like persistent data structures - object pooling is a similar concept), changing your algorithm to work in place, changing your algorithm to have fewer memory requirements, or even explicit marking of an object to be collected for GC while it's young (engines already often do some of their own pooling of frequently created objects). As for language help, you're on your own, because there's little the language can help you with, regardless of what's added. On Mon, May 9, 2016, 14:07 /#!/JoePea <j...@trusktr.io> wrote: > Thanks Andreas, that's helpful to know. In general, is there some way to > keep a list (adding removing things over time) while avoiding GC? > > For example, I thought I could place and remove items into a list (f.e. > Set or Map, while having my own references to all the items and the list > and outside of the list as well as to the list itself), but as you pointed > out that still can have need for GC. > > I know you said > > > In general, there is very little you can do in JavaScript that does not > potentially cause allocation and thus GC > > But, I would at least want to know that I minimized GC as much as > possible. My first hunch (for my case) would be to make a linked list out > of the items I need to have a "list" of, where each item's link (reference) > to the next item is also one of the references that I already hold outside > of the list? > > It seems that with Arrays (and Sets and Maps) that deleting an item from > the list also deletes the placeholder that was used for that item (in the > case of Array, the placeholders would be the numerical keys that are > deleted when an item is popped for example), and I'm guessing (with my > still expanding VM knowledge) that those placeholders are GCed separately > from the thing that was referenced to by the placeholder (so even if the > placeholder contained `null` there would still be GC). Is that a good guess? > > I'll be experimenting... > > On Mon, May 9, 2016 at 2:28 AM, Andreas Rossberg <rossb...@google.com> > wrote: > >> The `undefined` value is represented in exactly the same way as `true`, >> `false`, and `null` in V8. They're so called "oddballs" internally, global >> values that are neither allocated nor freed. >> >> Either way, the key/values of a (regular) map do not keep anything alive >> about the map. Adding or removing entries from a set or map can of course >> cause allocation/deallocation, regardless of the keys/values themselves. >> (Similarly if you are using regular objects as maps, btw.) >> >> There are also lots of other things that cause allocation/deallocation >> under the hood of a JavaScript engine, e.g. compilation, optimisation, >> deoptimisation, etc. Some of that predominantly happens at start-up. If you >> want to reduce random noise from your experiments, try to warm up the code >> first. But even then, don't read too much into micro-benchmarks -- JS VMs >> are far too complicated, dynamic, and heuristics-based to draw useful >> conclusions from tiny tests (that's e.g. why JSPerf tests are often >> bollocks). >> >> In general, there is very little you can do in JavaScript that does not >> potentially cause allocation and thus GC. Certainly nothing involving >> dynamic data structures. >> >> /Andreas >> >> >> On 5 May 2016 at 07:48, /#!/JoePea <j...@trusktr.io> wrote: >> >>> > The only v8 shell I have lying around is too old (3.14.5.10) to have >>> Set, so I can't tell you what it would do. >>> >>> On my first attempt, I noticed 8 Major GCs: >>> https://cloud.githubusercontent.com/assets/297678/15036715/f41ea4d4-1247-11e6-8823-f153c3c1b7bb.png >>> >>> On second attempt, no Major GCs: >>> https://cloud.githubusercontent.com/assets/297678/15036788/c066483a-1248-11e6-970b-3f9d20710bbc.png >>> >>> I wonder why. I'm in Chrome 50. >>> >>> So, the second attempt looks good. I'm not sure why the first is so >>> different. I tried it a few times, but I only got that Major GC zig-zag the >>> first time. >>> >>> Thanks for pointing out Set! >>> >>> On Wed, May 4, 2016 at 7:30 PM, Boris Zbarsky <bzbar...@mit.edu> wrote: >>> >>>> On 5/4/16 5:03 PM, Steve Fink wrote: >>>> >>>>> The only v8 shell I have lying around is too old (3.14.5.10) to have >>>>> Set, so I can't tell you what it would do. >>>>> >>>> >>>> I have v8 "4.8.0 (candidate)" (meaning whatever rev I checked out), and >>>> it does 1163 minor ("Scavenge") GCs on your testcase. It also does 1163 >>>> minor GCs if I take out the add() calls. It does none if I remove the >>>> clear() calls, no matter whether the add() calls are there or not. >>>> >>>> -Boris >>>> _______________________________________________ >>>> es-discuss mailing list >>>> es-discuss@mozilla.org >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>> >>> >>> _______________________________________________ >>> es-discuss mailing list >>> es-discuss@mozilla.org >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>> >> > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
