Another example that came to my mind after I wrote the comment above is that in comp. games frame timing can reveal critical information, i.e. act as ESP. In CS:GO for example the game does not know the position of enemy players at all times, the server only sends their positions if you could possibly perceive them. However, this does mean that if you are holding certain positions and the other team is sneaking up on you, you will experience a reduction in frame rate once your game starts to process them.

The entire game loop would need to be constant time w.r.t. player activity to avoid this issue!

> I'm 100% sure my Skyrim install is perfectly fine (it is a fresh one) and it does happen, just not frequently. If you haven't noticed it... well, as i already wrote, it isn't really noticeable.

My ability to detect lags of one second (like you wrote) is approximately 100 % assuming I am actually looking at the screen. I've seen pauses like this when I had a hard drive and with the 32-bit version of the game when it experienced memory pressure, and also due to badly written mods.

> And - especially on Skyrim - you'll also get way more variance than 1ms just walking around.

That's sadly true, though it tends to run smoothly when it has finished loading everything for an area.

Yes, the second-long pause was on the 32bit version, i do not remember noticing this in the 64bit SE version but i only bought that last week and my PC is in transit as i moved places so i haven't had enough time to see how that works. I have an SSD and relatively powerful computer though. In any case, my point is that it doesn't really matter as it doesn't affect anything and you'll notice pauses and performance hiccups way worse than 1ms not only in Skyrim, but in pretty much every high demanding game out there. Especially in open world games (hence the Skyrim reference) where the engines loads and unloads stuff all the time and there isn't a single point where you can have resources "settled". So that 1ms, if it happens rarely enough it wont be noticed by pretty much anyone.

The issue with GCs isn't really that 1ms, the issue is that some GCs (which sadly includes most known ones - like those in Java and C# - but not all GCs) do not provide any form of control beyond mere suggestions. For example last time i checked running System.gc() in Java doesn't really do a full GC run, so you cannot guarantee that by the time gc() returns you'll have all unused memory gone and placing that call between area/level loads in games (where the user expects some sort of delay anyway) doesn't help you much. Similarly you can't just "turn off" the GC until a later point (or until some specified failsafe threshold is reached) so you can't turn off the GC during normal levels and turn it on between level loads and/or when the player opens any inventory/menu/whatever screen (where again a tiny delay will be mostly unnoticed and/or ignored and often can be masked by the UI design) to clean up any garbage.

IMO a GC that gives you such control and takes 100ms is way more useful for games than a GC that give you no control and takes 1ms.