On Friday, 29 June 2018 at 16:49:41 UTC, Bauss wrote:
On Friday, 29 June 2018 at 16:07:00 UTC, Anton Fediushin wrote:
On Friday, 29 June 2018 at 11:11:57 UTC, rikki cattermole
wrote:
On 29/06/2018 11:09 PM, Anton Fediushin wrote:
It is GC's fault for sure, I built my program with
profile-gc and it allocated a lot there. Question is, why
doesn't it free this memory?
Probably doesn't know that it should deallocate so eagerly.
A GC.collect(); call may help.
That's a good idea. GC really needs to be kicked in once in a
while because it did _nothing_ in 8 hours, even though my
application is just a couple of timers - it isn't a hard task
for CPU or memory and there's plenty of time to collect some
garbage.
Now I finally understand why GC is not a great thing. I was
writing apps utilizing GC for a long time and never had
problems with it, but when it came down to this simple program
it stabbed me in the back.
I wouldn't really blame the GC. There is a higher chance you're
just not using it how it's meant to be, especially since it
looks like you're mixing manual memory management with GC
memory.
I am not quite sure what should I blame now, because even if I
use malloc for memory allocation, memory goes... somewhere?
So, long story short:
- Usage of Mallocator instead of theAllocator made it a little
bit better
- VibeManualMemoryManagement had no (or little) effect
- Manually calling GC.collect had no (or little) effect
It makes me think that error is somewhere else. I made a code
snippet of my testing program: https://gitlab.com/snippets/1729304
There are some changes to it:
- It uses different stream with metaint of 32KB
- It calls nowPlaying() every second
Now I will take a break from this, dealing with this kind of
nonsense annoys me.
