Hi guys! Still trying to get the hang of GLBasic, but I have a question. So far, I've only been testing on the Windows desktop, but I've noticed that a compiled .EXE consumes a pretty hefty portion: even a simple "Hello World!" example takes up nearly 1MB on disk, and consumes about 15MB at runtime.
Is this normal, and does it consume the same proportion of resources on mobile devices as well?
Quote from: TI-994A on 2012-Apr-09
Hi guys! Still trying to get the hang of GLBasic, but I have a question. So far, I've only been testing on the Windows desktop, but I've noticed that a compiled .EXE consumes a pretty hefty portion: even a simple "Hello World!" example takes up nearly 1MB on disk, and consumes about 15MB at runtime.
Is this normal, and does it consume the same proportion of resources on mobile devices as well?
What you have to remember is that the core of GLB framework is included with each EXE you produce, so a simple hello-world program compared to a more involved coded program would likely be very similar in size (upto a point). In BlitzMax there was a tool that scanned your code to see what libraries/modules could be excluded at compile to reduce the EXE size which was pretty awesome but you will always have some framework overhead.
You could always use something like UPX to pack your EXE afterwards to compress the EXE filesize. As for 15Mb at runtime that's pretty awesome I reckon :) lol.
I recall Mr. Tatoad´s books... one has a table on the executable sizes for multiple platforms as an example.
It is the GLBASIC PROGRAMMING REFERENCE GUIDE.
It has a little chapter called ´Executable sizes'.
It has a sample listed program, and it compares compiled sizes on multi plats.
It varies from ~1mb on win to ~12mb on mac and it has info on other platforms too as well as a hint on how to reduce win sizes.
I´m not sure this could help you out, but it is the only info I have on this to share.
My version of the book is not updated, so I´m not sure if things got added to that.
If you are really serious on glbasic programming, I have to recommend this book, the updated version.
It is a great companion to programming and the pdf versions are quite cheap should you wanna have it on a a second monitor or tablet.
Seriously, in this day and age does it really matter about .EXE size?
When 48KB was an absolute maximum for programs it was a problem, but when people have pc specs that have a very minimum of 256MB RAM (and more likely in excess of 1GB) it really isn't an issue. Even mobile platforms have enough memory to run anything GLB can produce.
BlitzMax has a more modular (and open) approach than GLB hence the ability to remove parts of the language that aren't required for the program; there are pros and cons to this approach.
And I agree that GLB is awesome, whether it uses 15MB of RAM or more or less =D
Hi guys, and thanks for the quick answers.
Quote from: spicypixel on 2012-Apr-09What you have to remember is that the core of GLB framework is included with each EXE you produce, so a simple hello-world program compared to a more involved coded program would likely be very similar in size (upto a point).
Thanks spicypixel, for that clear and concise explanation; You answered my question.
Quote from: erico on 2012-Apr-09I recall Mr. Tatoad´s books... one has a table on the executable sizes for multiple platforms as an example.
It is the GLBASIC PROGRAMMING REFERENCE GUIDE.
It has a little chapter called ´Executable sizes'.
It has a sample listed program, and it compares compiled sizes on multi plats.
It varies from ~1mb on win to ~12mb on mac and it has info on other platforms too as well as a hint on how to reduce win sizes.
Great resource; thank you for pointing it out, erico. I'll be sure to take a look.
Quote from: Ian Price on 2012-Apr-09Seriously, in this day and age does it really matter about .EXE size?
You surprise me, Ian. Even in the age of terabytes, I would think that memory-managing your apps would still be important to a serious programmer. For one, the size of the executable directly affects distribution and updates; the bigger apps will clearly have a bandwidth obstacle, especially on the mobile platforms. I believe that Apple has a 20MB cap (recently upped from 10MB) on apps that can be downloaded via the cellular networks; and that's not taking into consideration the per-byte bandwidth cost to the user.
And as far as runtime size is concerned, 15MB may seem irrelevant, but if the executable is going to grow proportionately from the "Hello World!" example (which was the original concern), it would be a real problem. In iOS, apps don't terminate by default, but rather get pushed into the virtual multitasking environment, where it continues to occupy precious RAM, and since they don't get purged unless other apps request for memory, they can cause the system processes to lag.
GLBasic is a great tool, no doubts about that; but defending it without basis with premises like "does EXE size really matter" is just not professional. The original question was simply a concern, and not a comparison or criticism.
In any case, as spicypixel & erico have so kindly pointed out, it may not be an issue, or at least one that can be managed, hopefully.
On ipad, running app with memory inspector shows 28~30mb ram consume...
QuoteYou surprise me, Ian. Even in the age of terabytes, I would think that memory-managing your apps would still be important to a serious programmer. For one, the size of the executable directly affects distribution and updates; the bigger apps will clearly have a bandwidth obstacle, especially on the mobile platforms. I believe that Apple has a 20MB cap (recently upped from 10MB) on apps that can be downloaded via the cellular networks; and that's not taking into consideration the per-byte bandwidth cost to the user.
I think Ian is only talking about windows .exe's where 1mb isn't a whole lot, Blitzplus was about 750kb
If i remember correctly Darkbasic's exe was about 5Mb, so really 1Mb isn't that large
The cap on cellular networks has been upped from 20mb to 50mb recently to allow for retina 3 graphics
You can test to see what size your mobile projects will be, by compiling for them and looking in the
distribute folder of your project
Quote from: okee on 2012-Apr-09
something on topic
I love your avatar. <3
Memory size management is of course more important on mobile devices that desktop machines - however keeping the size down on all platforms does of course help with program optimisation and execution efficiency.
This code :
PRINT "Hello World",0,0
SHOWSCREEN
KEYWAIT
Generates a 1,626,624 byte release program and the same size for debug mode - as Ian said, this is due to including all modules. However, you will find as program size increase the output size will only do so slowly. In addition variations of the code dont change program much (if at all). For example :
HelloWorld()
FUNCTION HelloWorld%:
INLINE
PRINT("Hello World",0,0);
SHOWSCREEN();
KEYWAIT();
ENDINLINE
ENDFUNCTION
Which is a lot less straight forward, produces an executable size of 1,626,624 in debug mode...
It does of course have a lot to do with the GCC compiler used for the platform - Windows still uses GCC 3.3, by the looks of things. Better optimisation could be obtained by using a later version.
Coding efficiency does, of course help here. However, what looks like more optimised code wont change the executables size (at least on Windows). This code :
LOCAL a%
a%=1
WHILE TRUE
PRINT a%,0,0
SHOWSCREEN
IF KEY(203)
DEC a%
ELSEIF KEY(205)
INC a%
ENDIF
WEND
produces an executable of the same size as :
LOCAL a%
a%=1
WHILE TRUE
PRINT a%,0,0
SHOWSCREEN
INC a%,(KEY(203)*-1)+(KEY(205)*1)
WEND
1,626,112 bytes.
Even using C produces a file exactly the same size :
DoCode()
FUNCTION DoCode%:
INLINE
int a=1;
while (true)
{
PRINT(a,0,0);
SHOWSCREEN();
a+=(KEY(203)*-1)+(KEY(205)*1);
}
ENDINLINE
ENDFUNCTION
It shows that even though the GCC backend is old, is does a pretty good job all the same. Whether execution speed is better with the later code or not is something that I will leave to other people to find out. :)
With mobile devices you also need to take into the account all the extra rubbish that Apple/Google insist must be added to make a valid application, which always increases the final result's size...
Quote from: Ocean on 2012-Apr-09Please note that that the linker used in the backend links in ALL the object files that are in the platform specific directory. As an example: in the Linux library directory, it will link in ALL .so files, even if some of these are not used by your application.
Thanks Ocean, for that useful detail.
Quote from: Hark0 on 2012-Apr-09On ipad, running app with memory inspector shows 28~30mb ram consume...
I hope you're not referring to the "Hello World!" example.
Quote from: okee on 2012-Apr-09I think Ian is only talking about windows .exe's where 1mb isn't a whole lot, Blitzplus was about 750kb
If i remember correctly Darkbasic's exe was about 5Mb, so really 1Mb isn't that large
Quote from: Ian Price on 2012-Apr-09Even mobile platforms have enough memory to run anything GLB can produce.
To be fair, he was talking about mobile platforms as well. And 1MB for a "Hello World!" example shouldn't be acceptable, let alone 5MB. Such a program on an optimised compiler would not take more than just a few kilobytes. But then again, GLBasic should not be included in that category, because it is clearly optimised for graphics/media intensive applications. Plus, it is seriously cross-platform.
Quote from: okee on 2012-Apr-09The cap on cellular networks has been upped from 20mb to 50mb recently to allow for retina 3 graphics
You can test to see what size your mobile projects will be, by compiling for them and looking in the
distribute folder of your project
I had no idea that it had been upped; thanks for that information, okee.
Reducing "Hello World" to less than 1MB is both pointless and more work than it's worth.
There a difference between the CORE service being large and the code that we produce. I DO optimize my OWN code constantly - there's nothing I can do about the CORE system (the GLB language itself). I have graphically and aurally intensive apps running on even limited hardware like the GP2X. I've never had to worry about running out of memory.
GP2X is the lowest platform that GLB supports (so far) - why worry about anything less? Let's face it a single .BMP image can be much more than the 1MB footprint and 2 MP3s can be more than the 15MB (even one can be) you're worried about when running the app. You can cut these back and reduce quality, but at the end of the day the media is more likely to be the biggest memory hog, not the language, not your code or your game data. It has ALWAYS been this way. We aren't living or working in th 8bit era nowadays.
Sure, you can go the radical encyption and crunching route, getting an app down to 4KB, but the time taken to un-crunch is pointless and the memory used at the end of the day will still be the same.
So stating that 1MB is unacceptable for a multi-platform core that offers 3D and NET control etc. etc. to me is pointless. 1MB is nothing.
However, I would also add that I don't accept that because we do have such large amounts of memory to play with that we should just fill it for the sake of it.
No mean to optimize under 1mb, simply due the core of libraries (SDL) that need to been include, even a simple "hallo" app need the SDL library included, so its cannot been avoided at all.
I have near 10000 commands count in Greedy Mouse and still only 3.2mb exe for Windows (and use about 25mb ram after graphics loading). So you should not have concern about that at all for exe size at all (wich of course various from platform to platform).
That, that take ram is using large offscreen buffers, big textures, caching, large wav and such thing. All is about content. More content you use = more ram do you use.
Quote from: Hark0 on 2012-Apr-09On ipad, running app with memory inspector shows 28~30mb ram consume...
I hope you're not referring to the "Hello World!" example.
No no :D This info are about my project NOT optmized yet.
Im very satisfaction... my files (png and wav) take about 9mb on disk, imagine when are loaded on iPad... Plus DIM and global variables... I think at the moment for me, are correct.
:)
Quote from: spacefractal on 2012-Apr-09
I have near 10000 commands count in Greedy Mouse and still only 3.2mb exe for Windows (and use about 25mb ram after graphics loading). So you should not have concern about that at all for exe size at all (wich of course various from platform to platform).
Right!
It's no the code produced... are the globals, variables, images, sounds.... that increase Ram consumition...
My Win32 exe have 1.7 mb... for iOS libPROGRAM.a are 522 kb.
Im currently using ~2500 commands...
:)
Why was my post deleted? Should I have not thanked MrTAToad? Or were my observations too close to home?Quote from: MrTAToad on 2012-Apr-09Memory size management is of course more important on mobile devices that desktop machines - however keeping the size down on all platforms does of course help with program optimisation and execution efficiency.
Hello MrTAToad, and thanks for the demonstrative examples; couldn't have said it better. And regardless of the overall efficiency of our code, or the compiler/platform in use, there's nothing we can do about the included core framework. After all, GLBasic is actually a RAD tool, and runtimes must be expected.
Quote from: Ian Price on 2012-Apr-09Reducing "Hello World" to less than 1MB is both pointless and more work than it's worth.
There a difference between the CORE service being large and the code that we produce. I DO optimize my OWN code constantly - there's nothing I can do about the CORE system (the GLB language itself). I have graphically and aurally intensive apps running on even limited hardware like the GP2X. I've never had to worry about running out of memory.
GP2X is the lowest platform that GLB supports (so far) - why worry about anything less? Let's face it a single .BMP image can be much more than the 1MB footprint and 2 MP3s can be more than the 15MB (even one can be) you're worried about when running the app. You can cut these back and reduce quality, but at the end of the day the media is more likely to be the biggest memory hog, not the language, not your code or your game data. It has ALWAYS been this way. We aren't living or working in th 8bit era nowadays.
Sure, you can go the radical encyption and crunching route, getting an app down to 4KB, but the time taken to un-crunch is pointless and the memory used at the end of the day will still be the same.
So stating that 1MB is unacceptable for a multi-platform core that offers 3D and NET control etc. etc. to me is pointless. 1MB is nothing.
However, I would also add that I don't accept that because we do have such large amounts of memory to play with that we should just fill it for the sake of it.
In the first place, a simple "Hello World!" program should never take up over a million bytes of code; it typically stands on only a few kilobytes at most. But, as spicypixel had explained earlier, the bloat is the GLBasic framework, which is definitely acceptable considering the amount of backend work it does for our codes.
Nowhere did I say "that 1MB is unacceptable for a multi-platform core that offers 3D and NET control", and I would appreciate it if you would not frivolously quote me out of context.
You, however, go on and on about code optimisation, talking about encryption(?) and crunching, and running on limited hardware, while at the same time condone using 1MB (BMP?) bitmaps and 15MB waves! Your initial stance on "EXE size doesn't matter" is clearly rooted in your coding practices. If you're not careful, memory can run out.
My posts were deleted too (I don't know by who), which clarified my statements and my points.
It would have been better to have just locked this thread rather than reduce it.
Mine too, a little bit draconian lol
Database issues? Webserver seemed a little bumpy yesterday/
I does not see its was deleted by moderator, elsewise the discussions and posts between would have a lots of holes (replys to none exists posts etc), so I gonna think its no more than a server issue, so could happens in other threads as well. Remember its happens as well in january. So nothing wrong here and a great topic, so I think no lock here.
I believe it could be that Ocean.
As just after posts got deleted, my ´show unread posts´ showed a few topics with no new thing or edits at all.
I looked like a restore.
Haven't noticed any weirdness - though it could be corrupt or something...
Quote from: Ian Price on 2012-Apr-09
My posts were deleted too (I don't know by who), which clarified my statements and my points.
It would have been better to have just locked this thread rather than reduce it.
Hi Ian! This little hiccup is a good wake-up call for me. Sorry if I was a little abrasive in my posts; it was nothing more than a juvenile reflex to your initial reply. We're all programmers here, and these little squabbles will in no way contribute to our overall productivity. To be honest, each of us have our own styles that work, so I'll try to leave the territorial showboating for the coding philistines.
Sincere apologies all round, especially to Ian, and thank you all for your replies; hope that I can learn from you.
Quote from: spacefractal on 2012-Apr-09
No mean to optimize under 1mb, simply due the core of libraries (SDL) that need to been include, even a simple "hallo" app need the SDL library included, so its cannot been avoided at all.
I have near 10000 commands count in Greedy Mouse and still only 3.2mb exe for Windows (and use about 25mb ram after graphics loading). So you should not have concern about that at all for exe size at all (wich of course various from platform to platform).
That, that take ram is using large offscreen buffers, big textures, caching, large wav and such thing. All is about content. More content you use = more ram do you use.
Hi spacefractal! That's exactly what I wanted to know. Thank you for providing those details.