Compile Sizes, An Observation.

[scurtyParticipant]

In Mx2 I’ve noticed we all usually just include “<std>” carelessly for each project independently. Now during the build process I’m assuming “<std>” imports everything you’d ever need while building a simple App, but at a higher risk of redundant unused code being copied and included in the final executable. Here is an Example. I’m Using Ubuntu Linux v16.04.

Simply not including “<std>” and having a bare-bones Mx2 file:

Monkey

Namespace APPLICATION Function Main() Print "Hello World" End

1 2 3 4 5

Namespace APPLICATION   Function Main() Print "Hello World" End

Will compile to a size of 74.6kb which is pretty awesome actually.
As soon as you include “<std>” It’s size increases to 2.9mb.

I was wondering while it’s great to have the convenience of “<std>” for bigger projects to maybe have the choice to explicitly “import” certain parts of a module in the final executable. File size obviously isn’t a concern on this scale but it’s still important to consider for large scale applications.

[codifiesParticipant]

I’d kind of assumed release compile would optimise and remove any unused code anyhow…?

have you noticed that #include seems to do nothing – not even cause an error! (typo I keep doing!)

[scurtyParticipant]

I’ve noticed the release build is 1.6mb instead of 2.9mb. I understand that most of the debug related functionality is being ignored by the compiler.

As for “#Include” and “#Import,” this would be a great opportunity to use “#Include” for including only sub-modules instead of the full core module, in the need of only a few parts of std, mojo/x, or any other library in use. Reducing compile size in the process.

So if you need ALL components of the std module just use #Import “<std>” and if you need only specific parts like “filesystem,” and “collections” for a simple App. You can; as an expample…

Note: Not sure if this is happening in the release build, but just an idea.

Monkey

#Include "<std/core>" #Include "<std/filesystem>" #Include "<std/collections>" ' Versus: '#Import "<std>" ' Using/compiling only what has been "INCLUDED". Using std.. Function Main() ' Codez End Function

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

#Include "<std/core>" #Include "<std/filesystem>" #Include "<std/collections>"   ' Versus:   '#Import "<std>"   ' Using/compiling only what has been "INCLUDED". Using std..   Function Main()       ' Codez   End Function

[nerobotParticipant]

You explore one way:

• include custom submodules of std
• using std.. (two dots after std).

The other way is to use

• import <std>
• and using custom submodules, like this
  • Using std.core
  • Using std.filesystem
  • etc….

But I don’t know will the output be optimized this way. Can you try ?

[degacParticipant]

Just an idea
Could be possible to create a sort of ‘import-alias’ pre-defined/programmed (by user or not)?
Something like

Monkey

Import <std> Using std.default

1 2	Import <std> Using std.default

where

std.default should be something like

Monkey

std.default=std.code,std.defined

1	std.default=std.code,std.defined

It should up to the compiler to ‘translate’ the std.default in the ‘proper’ Using std.X etc
So basically, if we are programming a game and we need gfx/sound/lan etc it could be exist a ‘preset’ std.game to use instead of write 10 different instructions.
Of course this should be *another* option, not a substitution of the actual solution implemented.

Hi

[nerobotParticipant]

For me it looks so difficult to use import-alias.

Instead of that we can create a file std.default.monkey2 and fill it:

Monkey

Import <std> Using std.core Using std.collections ' Using std.[other sub modules]

1 2 3 4

Import <std> Using std.core Using std.collections ' Using std.[other sub modules]

And import this file in our project via #Import “std.default”.

[Author]

Posts