ARSD PNG memory usage

[Joerg Joergonson via Digitalmars-d-learn]

On Friday, 17 June 2016 at 04:32:02 UTC, Adam D. Ruppe wrote:
> On Friday, 17 June 2016 at 01:51:41 UTC, Joerg Joergonson wrote:
>> Are you keeping multiple buffers of the image around? A 
>> trueimage, a memoryimage, an opengl texture
>
> MemoryImage and TrueImage are the same thing, memory is just 
> the interface, true image is the implementation.
>
> OpenGL texture is separate, but it references the same memory 
> as a TrueColorImage, so it wouldn't be adding.
>

ok, then it's somewhere in TrueColorImage or the loading of the 
png.

>
> You might have pinned temporary buffers though. That shouldn't 
> happen on 64 bit, but on 32 bit I have seen it happen a lot.
>

Ok, IIRC LDC both x64 and x86 had high memory usage too, so if it 
shouldn't happen on 64-bit(if it applies to ldc), this then is 
not the problem. I'll run a -vgc on it and see if it shows up 
anything interesting.

>> When I do a bare loop minimum project(create2dwindow + event 
>> handler) I get 13% cpu(on 8-core skylake 4ghz) and 14MB memory.
>
> I haven't seen that here.... but I have a theory now: you have 
> some pinned temporary buffer on 32 bit (on 64 bit, the GC would 
> actually clean it up) that keeps memory usage near the 
> collection boundary.

Again, it might be true but I'm pretty sure I saw the problem 
with ldc x64.

> Then, a small allocation in the loop - which shouldn't be 
> happening, I don't see any in here... - but if there is a small 
> allocation I'm missing, it could be triggering a GC collection 
> cycle each time, eating CPU to scan all that wasted memory 
> without being able to free anything.
>

Ok, Maybe... -vgc might show that.

> If you can run it in the debugger and just see where it is by 
> breaking at random, you might be able to prove it.
>

Good idea, not thought about doing that ;) Might be a crap shoot 
but who knows...

> That's a possible theory.... I can reproduce the memory usage 
> here, but not the CPU usage though. Sitting idle, it is always 
> <1% here (0 if doing nothing, like 0.5% if I move the mouse in 
> the window to generate some activity)
>
>  I need to get to bed though, we'll have to check this out in 
> more detail later.
>
me too ;) I'll try to test stuff out a little more when I get a 
chance.

>
>> Thanks!  Also, when I try to run the app in 64-bit windows, 
>> RegisterClassW throws for some reason ;/ I haven't been able 
>> to figure that one out yet ;/
>
> errrrrr this is a mystery to me too... a hello world on 64 bit 
> seems to work fine, but your program tells me error 998 
> (invalid memory access) when I run it. WTF, both register class 
> the same way.
>
> I'm kinda lost on that.

Well, It works on LDC x64! again ;) This seems like an issue with 
DMD x64? I was thinking maybe it has to do the layout of the 
struct or something, but not sure.

---

I just run a quick test:

LDC x64 uses about 250MB and 13% cpu.

I couldn't check on x86 because of the error

phobos2-ldc.lib(gzlib.c.obj) : fatal error LNK1112: module 
machine type 'x64' conflicts with target machine type 'X86'

not sure what that means with gzlib.c.ojb. Must be another bug in 
ldc alpha ;/


Anyways, We'll figure it all out at some point ;) I'm really 
liking your lib by the way. It's let me build a gui and get a lot 
done and just "work". Not sure if it will work on X11 with just a 
recompile, but I hope ;)