You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi.
I noted quite a difference on memory usage, I wonder if this is normal behavior or a problem in my compilation process.
I am comparing moonnuklear against the nuklear's GDI demo on private memory usage.
Is there anyway to have moonnuklear with the GDI backend for a fair comparison?
Windows GDI hello world in C
The text was updated successfully, but these errors were encountered:
Hi.
You can write backends using whatever graphics API you like, as long as you can access them from Lua. That is, you need bindings to the API, or to higher level functions that use the API to give you the functionalities you need (e.g. bindings to functions provided by the GDI based backend itself).
As for the above comparison, I honestly can't say if it signals something anomalous. The difference in memory usage may partly be explained by the different graphics API (I expect GDI being better tailored to the OS than OpenGL).
But apart from that, a Lua/moonnuklear application will always have a bigger memory usage than a corresponding nuklear application written in C or C++. All else being equal, in the former you have the overhead of the additional Lua layer. Memory is allocated by the Lua interpreter as well as by the binding libraries (MoonNuklear, MoonGL, MoonGLFW etc), a price one pays for having the translation from C to Lua and viceversa.
Add to this the fact that Lua is a garbage collected language, so the memory footprint also depends on the adopted GC policy and may be quite variable in time.
Hi.
I noted quite a difference on memory usage, I wonder if this is normal behavior or a problem in my compilation process.
I am comparing moonnuklear against the nuklear's GDI demo on private memory usage.
Is there anyway to have moonnuklear with the GDI backend for a fair comparison?
Windows GDI hello world in C
The text was updated successfully, but these errors were encountered: