4 ms·

Same for Javascript, at least when aiming for perfect 60FPS, the only good garbage collection is the one that doesn't occur after init, and maybe when switching

Same for Javascript, at least when aiming for perfect 60FPS, the only good garbage collection is the one that doesn't occur after init, and maybe when switching maps or whatnot. Even the 0.09ms in the article is way too much and means a skipped frame. Maybe a way to think of it is to treat GC like optional automatic destructors, which should get called (more or less) when you want them to, not as something you just "don't have to think about" (if you run something in a loop and need it to be silk smooth, that is). Incidentally, this is great: https://www.mozilla.org/en-US/firefox/46.0beta/releasenotes/ https://www.mozilla.org/en-US/firefox/46.0beta/releasenotes/ > Allocation and garbage collection pause profiling in the performance panel

ygra 11y ago
> Even the 0.09ms in the article is way too much and means a skipped frame. He wrote 0.09 seconds. In any case, if you're generating megabytes to gigabytes of garbage in a single frame you probably deserve a GC pause.
- JoeAltmaier 11y ago
  Its very hard to control garbage. So many operations have unavoidable garbage side effects, especially involving immutable arguments.
  - _ph_ 11y ago
    A good GCed language should give you good controls about garbage generation. If you have not these controls, the language is to blame, not the concept of GC. But indeed, I think one of the strongest disadvantages of Java is that it does not give you much control about garbage generation.
    - whateveracct 11y ago
      What languages give you more control over GC than Java? My only experience is Java and Go. Go gives you literally one knob, whereas Java allows you to tune MANY factors on top of picking a collector.
      - pjmlp 11y ago
        Modula-3, just as one possible example. Sadly the whole set of DEC, Compaq, HP acquisition processes killed it.
      - _ph_ 11y ago
        I was talking about garbage generation. For best performance, you want to control heap allocation and the memory layout. Java gives you no controls there. All objects in Java are heap allocated, you can reference them only by pointer. In Go you can have value-types. An array in Go can be a block of structures, while in Java it would have pointers to separately allocated object. Also, if you have objects as member variables in a Java object, they cannot be part of that object, but need to be separate objects on the heap. This limits quite a few optimizations.
- PavlovsCat 11y ago
  Oops, sorry. I did write ms, but meant seconds. Even 9ms would be too much, but 90ms would be crazy in a game. Though megabytes of garbage are easy to "achieve" if you don't pool objects, call functions with temporary objects as parameters or return values, etc. It really just depends on how much you do that way, which can easily be a way that works fine during execution, or even seems really elegant, but bites you in the ass at GC time. Especially since 60 frames a second doesn't mean you're not running some other loop for the logic more often than that, and it's not like you ever have the full 16ms for rendering and logic either. "Silky smooth" to me means no dropped frames, none, once the game loop is running and the JIT warmed up. A browser might never be able or willing to guarantee that, but even a few megabytes to GC every 10 seconds means a guaranteed hiccup. Yeah, you can't avoid outside influences, but you can avoid your code dropping frames even in a vacuum. Nothing more, nothing less, and right now, for Javascript in browsers, that means knowing when to avoid GC among other things. As far as I can tell, and while I'd be happy to be proven wrong, I'm not sure anyone even honestly engaged with it, much less disproved it. Say you have a game that might spawn and kill hundreds or thousands of enemies and/or projectiles per frame, and those enemies are more than just a pair of coordinates. You simply can't use something like new/delete for that, period. If you haven't even tried, be it in the context of game or something comparable, and dismiss what I say based on some notion of what I "deserve" or what one should criticize about a language (when I was simply talking about what you need to do today, to get a specific thing done in a specific environment), you're really missing out. The question (to me) isn't what language should you use to make the most accessible kind of simple game, the question is how to get shit done in Javascript. I'd be happy to try something better before it gets adopted, but no, I won't pour a lot of work into a game made with it, I might dabble and if I fall in love I might advertise it, but to lay a foundation I might be still using years later, that does need the adoption having taken place (past tense), not it being the objectively best idea. I'm not "complaining about GC" either, I do prefer it to memory holes. But show me anyone writing seriously about making games with Javascript claiming you shouldn't pool objects etc., or decent libraries that don't do it for you. I'll happily admit I don't know much, but this one I laboured over and read about and experimented with more than enough (because I just couldn't get rid of the hiccups, no matter how simple I made things) to be rather sure of what I said above. I know it's off-topic, I know people might not care, I know it's no great insight, but that doesn't make it false. It was something that tripped me up and which made a huge difference to me, and it's something I see very rarely discussed outside of people actually making games. That's why I brought it up, hopefully those actually engaging in anything that might benefit from this will look into it, enjoy and you're welcome. https://hacks.mozilla.org/2013/05/optimizing-your-javascript-game-for-firefox-os/ https://hacks.mozilla.org/2013/05/optimizing-your-javascript... > JavaScript can spoil us when it comes to memory management. We generally don’t need to worry about memory leaks or conservatively allocating memory. But if we’ve allocated too much and garbage collection occurs in the middle of a frame, that can take up valuable time and result in a visible drop in FPS. And since as of yet there is no way to control when GC occurs, and no way to enforce it not taking longer than X ms, you have to know how to avoid it. It's not that you always have to avoid it, but you do need to know how to, at least if you write a smooth game, a physics library etc., anything that runs for a while in a quick loop and does more than a handful things which should not drop frames when avoidable.
cmrdporcupine 11y ago
Ah for the good old days when we just tied our animation routines to a vertical blank interrupt and that was that. :-)

ygra 11y ago

> Even the 0.09ms in the article is way too much and means a skipped frame. He wrote 0.09 seconds. In any case, if you're generating megabytes to gigabytes of garbage in a single frame you probably deserve a GC pause.

JoeAltmaier 11y ago
Its very hard to control garbage. So many operations have unavoidable garbage side effects, especially involving immutable arguments.
- _ph_ 11y ago
  A good GCed language should give you good controls about garbage generation. If you have not these controls, the language is to blame, not the concept of GC. But indeed, I think one of the strongest disadvantages of Java is that it does not give you much control about garbage generation.
  - whateveracct 11y ago
    What languages give you more control over GC than Java? My only experience is Java and Go. Go gives you literally one knob, whereas Java allows you to tune MANY factors on top of picking a collector.
    - pjmlp 11y ago
      Modula-3, just as one possible example. Sadly the whole set of DEC, Compaq, HP acquisition processes killed it.
    - _ph_ 11y ago
      I was talking about garbage generation. For best performance, you want to control heap allocation and the memory layout. Java gives you no controls there. All objects in Java are heap allocated, you can reference them only by pointer. In Go you can have value-types. An array in Go can be a block of structures, while in Java it would have pointers to separately allocated object. Also, if you have objects as member variables in a Java object, they cannot be part of that object, but need to be separate objects on the heap. This limits quite a few optimizations.
PavlovsCat 11y ago
Oops, sorry. I did write ms, but meant seconds. Even 9ms would be too much, but 90ms would be crazy in a game. Though megabytes of garbage are easy to "achieve" if you don't pool objects, call functions with temporary objects as parameters or return values, etc. It really just depends on how much you do that way, which can easily be a way that works fine during execution, or even seems really elegant, but bites you in the ass at GC time. Especially since 60 frames a second doesn't mean you're not running some other loop for the logic more often than that, and it's not like you ever have the full 16ms for rendering and logic either. "Silky smooth" to me means no dropped frames, none, once the game loop is running and the JIT warmed up. A browser might never be able or willing to guarantee that, but even a few megabytes to GC every 10 seconds means a guaranteed hiccup. Yeah, you can't avoid outside influences, but you can avoid your code dropping frames even in a vacuum. Nothing more, nothing less, and right now, for Javascript in browsers, that means knowing when to avoid GC among other things. As far as I can tell, and while I'd be happy to be proven wrong, I'm not sure anyone even honestly engaged with it, much less disproved it. Say you have a game that might spawn and kill hundreds or thousands of enemies and/or projectiles per frame, and those enemies are more than just a pair of coordinates. You simply can't use something like new/delete for that, period. If you haven't even tried, be it in the context of game or something comparable, and dismiss what I say based on some notion of what I "deserve" or what one should criticize about a language (when I was simply talking about what you need to do today, to get a specific thing done in a specific environment), you're really missing out. The question (to me) isn't what language should you use to make the most accessible kind of simple game, the question is how to get shit done in Javascript. I'd be happy to try something better before it gets adopted, but no, I won't pour a lot of work into a game made with it, I might dabble and if I fall in love I might advertise it, but to lay a foundation I might be still using years later, that does need the adoption having taken place (past tense), not it being the objectively best idea. I'm not "complaining about GC" either, I do prefer it to memory holes. But show me anyone writing seriously about making games with Javascript claiming you shouldn't pool objects etc., or decent libraries that don't do it for you. I'll happily admit I don't know much, but this one I laboured over and read about and experimented with more than enough (because I just couldn't get rid of the hiccups, no matter how simple I made things) to be rather sure of what I said above. I know it's off-topic, I know people might not care, I know it's no great insight, but that doesn't make it false. It was something that tripped me up and which made a huge difference to me, and it's something I see very rarely discussed outside of people actually making games. That's why I brought it up, hopefully those actually engaging in anything that might benefit from this will look into it, enjoy and you're welcome. https://hacks.mozilla.org/2013/05/optimizing-your-javascript-game-for-firefox-os/ https://hacks.mozilla.org/2013/05/optimizing-your-javascript... > JavaScript can spoil us when it comes to memory management. We generally don’t need to worry about memory leaks or conservatively allocating memory. But if we’ve allocated too much and garbage collection occurs in the middle of a frame, that can take up valuable time and result in a visible drop in FPS. And since as of yet there is no way to control when GC occurs, and no way to enforce it not taking longer than X ms, you have to know how to avoid it. It's not that you always have to avoid it, but you do need to know how to, at least if you write a smooth game, a physics library etc., anything that runs for a while in a quick loop and does more than a handful things which should not drop frames when avoidable.

cmrdporcupine 11y ago

Ah for the good old days when we just tied our animation routines to a vertical blank interrupt and that was that. :-)