koobas.hobune.stream
GC allocation: Is 24B every frame acceptable for mobile platforms?
Hi.
I'am generating road by calculating next point, assigning it to the List and deleting first one if List is too big. I could recalculate point at the index of list and move start index to prevent creating new point, but this would break my clean code. My question is if 24B of gc allocation every frame is acceptable? If yes, what is the acceptable limit?
(I'am using List instead of Queue, because ironically it's faster and easier to iterate)
Best regards, Atezai.
You don't ever touch GC manually. Ever. Forget it and toss the idea. It does its little optimized thing. You cant do better. Ever :)
I didn't mean to do it manually. I can recalculate point at the index of the list, ins$$anonymous$$d of creating new one and adding it to the list. I'am just curious if this extreme optimisation at every step has sense, and what are the limitations.
Here's the thing with gc: if there's a ton of spare memory to allocate, there's no reason not to do it. Gc runs in 2 ocasions: 1. low memory for other things to run; 2.extremely large object to load and it cant fit into current heap. Your app calculates managed heap on the start, to it's pretty much optimized for everything you might possibly want to load. As your second note on using List ins$$anonymous$$d of Queue. Queue's deQueue does exactly what you're doing with List.RemoveAt (0).
