|
Re: compiler and memory usage
[Re: jcl]
#466453
06/14/17 20:40
06/14/17 20:40
|
Joined: Sep 2003
Posts: 6,861 Kiel (Germany)
Superku
Senior Expert
|
Senior Expert
Joined: Sep 2003
Posts: 6,861
Kiel (Germany)
|
I'm just using the default nexus and "run current script". I've created a small test example thingy that demonstrates the problem: http://superku.de/codeCompileTest.zipVMMap if you do not have it already: https://technet.microsoft.com/en-us/sysinternals/vmmap.aspxThe code_creator.c creates a few files with copy pasted dummy functions and different names. That has been done already though, just run main.c. The compiler will stop after it has processed all the code and reached "asasda" after the main function. When you select that acknex process with VMMap, it will show a heap value of ~1041MB (unless my system is bugging out right now again, which I don't think it is). No images or global objects, except stuff from default.c (and acknex.h). Remove "asasda" and run current script again. The A8 window appears. VMMap on that process returns a heap size of ~~1223MB. If you now press [Space], bmap_createblack(2048,2048,32)+draw_quad is executed each frame. The application throws the known DirectX error after about (on my machine) 22 bitmaps (which makes sense, 22*2*8MB = 352MB, default critical heap value). ------------------------------ Btw. I've copy pasted some more (of the same) dummy code into dummyFunction.txt, ran code_creator.c again and main.c after. Got no code size warning but a Microsoft Vusual C++ Runtime Library Runtime Error! Program: ... acknex.exe This application has requested the Runtime to terminate it in an unusual way. VMMap: Total 2028MB, Heap 1864MB. This is not working as intended, right? Thanks for your time.
"Falls das Resultat nicht einfach nur dermassen gut aussieht, sollten Sie nochmal von vorn anfangen..." - Manual Check out my new game: Pogostuck: Rage With Your Friends
|
|
|
Re: compiler and memory usage
[Re: HenWoll]
#466503
06/18/17 21:33
06/18/17 21:33
|
Joined: Dec 2011
Posts: 1,823 Netherlands
Reconnoiter
OP
Serious User
|
OP
Serious User
Joined: Dec 2011
Posts: 1,823
Netherlands
|
Now, however i can only Maximum change to 2 level,s after this i become the Error E1513, In the most diverse varieties!
The levels individually can be run and error-free, only that my video memory fills quickly after Level Load .
Someone has a suggestion where I should start? , perhaps it some texture(s) that is not freed by level_load (bmap_create and/or extra panels?). If yes, try bmap_purge / ptr_remove them. I think I can keep loading quite big (in terms of memory) levels but I mostly use entities so they get automatically purged. My panels are currently mostly placeholder tiles and I dont think I really use bmap_create except for some initialization of some icons. I quess its something bmap / bmap_create related. Perhaps also try debugging with sys_marker incase you already haven't. Also d3d_texdepth = 16; helps (but not for memory leaks ofcourse).
Last edited by Reconnoiter; 06/18/17 21:35.
|
|
|
Re: compiler and memory usage
[Re: Reconnoiter]
#466519
06/19/17 09:33
06/19/17 09:33
|
Joined: Jul 2000
Posts: 27,986 Frankfurt
jcl
Chief Engineer
|
Chief Engineer
Joined: Jul 2000
Posts: 27,986
Frankfurt
|
Ok, I've checked your example. The compiled code size is not 980 MB, but about 10 MB. This is indeed a problem, since the compiler first compiles the script to an interim code and then to the final machine code. The interim code can be much larger than the machine code, up to factor 30. The compiler also allocates all sorts of additional data structures since it's made for speed, not for memory preservation. All this inflates the memory allocation at compile time to a large multiple of the original code size.
When the script is then run afterwards, some of the memory is freed, but a large part stays allocated for the purpose of debugging and accessing variables. Only when the script is compiled to a published exe and then executed, that memory is not allocated.
There's certainly room for optimization since I think 90% of the allocated memory by the compiler is not needed at runtime. But that's how it works at the moment.
|
|
|
Re: compiler and memory usage
[Re: jcl]
#466566
06/21/17 13:43
06/21/17 13:43
|
Joined: Sep 2003
Posts: 6,861 Kiel (Germany)
Superku
Senior Expert
|
Senior Expert
Joined: Sep 2003
Posts: 6,861
Kiel (Germany)
|
Thanks for looking into it. a large part stays allocated for the purpose of debugging and accessing variables Is that for the "Debug run" in SED (only)? If so, could that be optionally skipped/ excluded from the acknex build for "Run current script"/ "Test run"? I actually never use the "Debug run" as it for some reason never worked for me. When I see its features I should probably have dug more into it. If that (quote) includes stuff like sys_marker, sys_malloc and so on it has definitely got to stay though. There's certainly room for optimization since I think 90% of the allocated memory by the compiler is not needed at runtime. But that's how it works at the moment. Ok, glad that this memory mystery is finally solved! Would be nice if this could be improved/ done some time in the future as it's such a big issue for non-published test runs.
Last edited by Superku; 06/21/17 13:45.
"Falls das Resultat nicht einfach nur dermassen gut aussieht, sollten Sie nochmal von vorn anfangen..." - Manual Check out my new game: Pogostuck: Rage With Your Friends
|
|
|
|