4.1.4 Compiler 2 Beta code size comparsion

Frequently "the obvious" is well worth stating. I spent many hours a couple of years ago splitting my main processing function into a slew of smaller, single-call functions to handle independent cases.

I'm not sure that it cost any processing cycles, but it saved a heap of memory as there were a lot of local variables which were able to be defined in their own function and so quickly released.

It certainly made the code readable.

Alan.raceQs said:

 it saved a heap of memory as there were a lot of local variables which were able to be defined in their own function and so quickly released.

But couldn't you achieve the same effect and save a tiny bit more memory simply by assigning null to a local variable when you were done with it? Or by simply creating a new block scope for each smaller conceptual function?

I'm not saying it would be worth the hit in readability or maintainability.

Anyway, you'll just have to take my word for it that I was able to save lots of memory by inlining stuff in some of my apps. ¯\_(ツ)_/¯

FlowState said:

Or by simply creating a new block scope

What's a "block scope" (in MonkeyC)?

FlowState said:

assigning null to a local variable

I can't imagine anything more mind numbing!

But anyway my primary objective was to make the code more readable, and that worked 100%

FlowState said:

Anyway, you'll just have to take my word for it

Trust me, I'm from the government!

Alan.raceQs said:

FlowState said:

assigning null to a local variable

I can't imagine anything more mind numbing!

But anyway my primary objective was to make the code more readable, and that worked 100%

I never said it was fun or a good practice, I just said it would be a way to achieve the same effect (saving memory) without making a new function.

Alan.raceQs said:

What's a "block scope" (in MonkeyC)?

The same thing it is in most C-style languages: a region of code that's created with an opening "{"  and terminated by a closing "}".

https://www.geeksforgeeks.org/scope-rules-in-c/

Scope of a Identifier begins at opening of the block / ‘{‘ and ends at the end of the block / ‘}’. Identifiers with block scope are local to their block

e.g.

    function foo() {
        { // beginning of new block scope
            var x = 42;
            System.println("x = " + x);
        } // end of new block scope
        System.println("x = " + x); // Compile error, as x is unavailable here
    }

Alan.raceQs said:

FlowState said:

Anyway, you'll just have to take my word for it

Trust me, I'm from the government!

Since you asked so nicely, I'll give you a hybrid example from 5 years ago where I converted a stack class to one function and a bunch of manually inlined functions (like peek()), which saved a bunch of memory both in code and data (since objects are expensive).

If you need something more than that, sorry you'll just have to use your imagination, look at your own code for inspiration, or ask google/stackoverflow.

https://stackoverflow.com/questions/280173/c-inline-functions-and-memory-use

in general, inlining code will increase how much memory is used to load your program. This is because there will be multiple copies of the generated code scattered around your program. However, this isn't always true -- if your inlined function was only used once, there's little change, and if the inlined function is very small, you could get a net reduction in code size by removing the function call overhead.

Sorry for the images, but the forum literally won't let me paste my code and I don't feel like using pastebin.

Original code:

New code:

In my specific app, I would've seen gains just by inlining peek() and pop(), but obviously I saved a lot more by getting rid of the Stack class itself. (Since I saved on all the overhead for the class and object stuff.)

Not to mention that another obvious type of candidate for inlining is "accessor/mutator type" functions in classes, which are often dead simple in terms of implementation.

e.g. Good design:

class Stack {
  private var _size;
  public function size() {
    return _size;
  }
  // ...
}

Bad design, but saves precious bytes in Monkey C

class Stack {
  public var size;
  // ...
}

In well-designed programs, we often have very trivial functions which only exist abstract/hide/prevent access to the internal state of the object, to prevent coding errors, to allow the external interface of a class to stay the same while the internal implementation changes, etc.

From a memory efficiency POV, when every byte counts, good design is a waste of memory.

Thank you for your detailed response, but I think any response will inexorably entrench us on opposite sides of the debate over the value of Object Oriented program design. And that won't benefit either of us.

Alan.raceQs said:

Thank you for your detailed response, but I think any response will inexorably entrench us on opposite sides of the debate over the value of Object Oriented program design. And that won't benefit either of us.

I never said I cared or didn't care about OOP design one way or another. I literally removed as many classes from my monkey C apps as possible in order to save on code. And in my day job, I mostly work with functional code where OOP is either a secondary concern or completely absent. On the other hand, in previous jobs I wrote a lot of heavily object-oriented code. And maybe 20-30% of my current job still involves OOP.

I do think that if you're going to do OOP (e.g. you're using Monkey C where it's impossible to not use a few classes), you may as well do it the right way. But of course Monkey C doesn't let you go all-in on OOP without consuming lots of memory.

But I'm not married to the idea of OOP, nor do I reject it out of hand. It has its uses, but it's not appropriate everywhere. (The modern trend is obviously to move away from OOP for a lot of reasons.) If I had much larger amounts of memory available for my CIQ apps, I'd have no problems always writing Monkey C code the "right way" (as intended by the designers).

I just pointed out that there's some situations where there could be functions that are simple enough to inline in a way that saves memory, since you demanded it. If I really wanted to, I could find stuff that has nothing to do with OOP at all.

Like I'm not literally gonna go through my entire git history for all my monkey C apps to find some salient, non-trivial, non OOP pieces of code that I inlined in order to prove a point to you. Even if I did that, what would it prove? Who's to say you would write that kind of code in the first place?

If you really want to believe that inlining can never save memory except for some contrived examples that I made up, that's fine with me.

I simply made the statement that for *me*, I was able to save lots of memory by inlining code in Monkey C. This is code that was originally written in a readable and maintainable way, but wasted memory in code. I reclaimed that wasted memory with manual inlining (which made the code much harder to read and maintain.)

This was in response to your blanket statement that you believe inlining increases memory usage.

So there's at least 3 exceptions:

1) My personal experience

2) The experience of the people who wrote the wikipedia article on optimization who claimed that inlining usually wastes memory but sometimes saves it

3) The experience of the person who wrote the monkey C prettier tool which includes an inlining feature

I just wanted to mention that because inlining was very useful for me, specifically for Connect IQ Monkey C development, and specifically for saving memory on memory-limited devices. The key is obviously you have to identify which functions are good candidates for inlining, and verify your guesses through trial and error.