THEMA:

Have look on how you can save quite a lot of memory: www.rc-thoughts.com/2017/01/precompile-l...ave-a-lot-of-memory/

Great job from Jetimodel!

Hi Tero,

thanks for testing and publishing.

Are the Memory savings in your Chart compared to the minified source code ?

Best regards
Bernd

Sepp62 schrieb:

Hi Tero,

thanks for testing and publishing.

Are the Memory savings in your Chart compared to the minified source code ?

Best regards
Bernd

No, I don't use minified code. Minifying code makes so little difference according my test's so comparing the small gain to very hard to read code simply makes me stick to "normal" code.

The most gain would of course be that after writing the app you would first minify it and then compile it.

There is one thing you have to remember when using minifier:

It makes same variable-names across apps. If you look at the code after minifying you'll se variables starting from a forward. Since we cannot have just local variables and in some cases have to use globals using minifying on all apps and running several apps at the same time causes problems.

Yes. Minification will definitely be "second choice" compared to compilation.

Jeti should switch the concept to "automatic compilation". This means that you put the text script to the apps folder and the transmitter automatically generates and loads the compiled version.

Sepp62 schrieb:

Yes. Minification will definitely be "second choice" compared to compilation.

Jeti should switch the concept to "automatic compilation". This means that you put the text script to the apps folder and the transmitter automatically generates and loads the compiled version.

It does that already.

Point is that it does that when you load the app and that means when you change model or start transmitter and all that takes memory.

I know you mean that transmitter should compile the app once, save a compiled file and then use that in future. I don't think that is an answer personally. I mean, in 24 there's no issues with apps, we're not even close to max memory-use. We will be sometime but we need to get more possibilities too. In 16 we have a limit, and it's 30kB. We can save some kB with compiling apps but then starts the cat and mouse-game. If I can run a code with X amount of functions with Y amoun kB, and save something by compiling then I surely can add functions so it doesn't run again, run? Then compile it and voilá, it runs! See where I'm going with this?

We can do whole lot with Lua even in 16 and 30kB, but never everything, in 24 we can.

I think this "Hey 16 user's, have a little taste of Lua!" is brilliant marketing from Jetimodel

I am already satisfied when I see, that there is no dependency between "source code structure" (which means variable name lengths, comment lengths, etc.) and memory consumption.

You write, that Jeti already converts source code to binary representation. The consequence is, that i.e. long variable names should not affect memory consumption except during text to binary conversion at model startup.

Unfortunately I could not find a way to display the amount of used memory. When adding a Lua application to model, the file size is displayed. But what is the actual amount of memory consumed ? (program memory plus Lua stack). Is there a way to get actual memory usage ?

It is definitely true, that saving program memory is only one part in the whole game. Lua scripts on a Dx16 always will be critical, since there is no surplus in memory as in DC24. For example: If you use system.GetSensors() stack memory consumption will vary, depending on the number of sensors. So one and the same script will run on system1 but not on system2 (as you already stated in your last answer). Who will found out the reason in the particular case ?

Your insinuation, that Lua on a Dx16 might be brilliant marketing, could become a boomerang for Jeti , when "system reliabilty" is going to become vague.