On Thursday, 28 July 2016 at 16:45:05 UTC, bitwise wrote:
On Thursday, 28 July 2016 at 16:15:04 UTC, Guillaume Piolat
wrote:
On Thursday, 28 July 2016 at 15:24:10 UTC, bitwise wrote:
It's not about running out of memory. It's a performance
issue.
Example: In the following class, it would be perfectly fine,
and even expected to allocate in start() but not in update().
This is because start() gets called once on object
initialization, but update() would get called every frame.
Vladimir implemented counting in -profile=gc, it gives you the
number of allocations and the amount allocated for each
allocation point.
I'm not sure if this point is meant to be for or against what
I'm suggesting, but still, I'm thinking in terms of
*proactively* writing efficient code, not allowing an app get
to the point where you need to run a profiler.
Well, here in my opinion there's the wrong attitude of profiling
only when it becomes necessary (i.e. the app is slow or uses too
much ram). This is wrong. You should profile before this happens;
you should profile to see if the time/memory is spent in the
parts of the application that should spend it and you should
profile whenever you care about making good code and not just
"code that works". You should profile while you add features, to
see their impact on the overall performance. Profiling at the
end, when you have a 100K LOC codebase deployed, because a user
ran out of memory is too late: too late to allow to easily spot
the problem and too late to think an alternative
approach/algorithm/design, instead of just patching the problem.
