Reducing/Optimizing Memory Usage (not texture)

Solar2D Lua Language
#1

Hi,
I’m asking is there a guideline to reduce the memory usage of your tables in general. I’m trying to create an application where it generally creates thousands of instances of tables.
By tables I mean objects/classes. This is a typical class construct that I do in Lua based on some OOP with Lua tutorial :

function classFoo()  
 local instance={  
 member1=0,member2,.....  
 }  
 instance:method1()  
 end  
 instance:method2()  
 end  
 instance:method3()  
 end  
 .....  
end

As the class gets complicated I added more methods and members and my memory usage just shoot through the roof :frowning:
Is there a guideline on what/what not to do if I don’t want Lua to use much memory?

Thanks [import]uid: 76697 topic_id: 33064 reply_id: 333064[/import]

#2

It sounds like the implementation may be doing something very inefficient, like storing individual method pointers with the objects (possibly dozens per object), perhaps, as opposed to a single class method pointer to the entire classes methods (for example).

There are ways you can test to find out which aspects of your object creation/data/usage are really impacting your memory usage (and then take steps to circumvent the issues).

To preform some tests, you could make a “test harness” program (a little program to hold your test code), which will just create certain objects and print out some memory information. Test harness programs are usually very short, with some basic code for your app pasted in, and a little control code.

First, the test harness would create 100,000 (or some other large number) of your standard objects, take the memory reading and store it/print it.

Immediately after that, the test harness would create 100,000 slightly different objects… (with extra/removed data elements, or extra/removed methods), and then store/print that.

If there are other aspects of the objects to check, the test harness would also exercise and measure those as well.

Once you have the results, you’ll have an idea of what aspect of the objects is eating up memory, and can devise an alternate strategy to manage those elements more efficiently. [import]uid: 79933 topic_id: 33064 reply_id: 131330[/import]

#3

Yes, that’s what i’ve been trying to do as well. Do you have any tips on how to print/debug from the terminal windows in corona?
It’s really hard to scroll up/down to see the dump prints and in windows i really cant scroll up to the 1st line.
[import]uid: 76697 topic_id: 33064 reply_id: 131338[/import]

#4

I’m using the mac, sorry. You could cut the amount of output to just a few critical things, or always print them last…

Maybe some windows user knows a way to expand the console buffer? [import]uid: 79933 topic_id: 33064 reply_id: 131340[/import]

#5

It sounds like the implementation may be doing something very inefficient, like storing individual method pointers with the objects (possibly dozens per object), perhaps, as opposed to a single class method pointer to the entire classes methods (for example).

There are ways you can test to find out which aspects of your object creation/data/usage are really impacting your memory usage (and then take steps to circumvent the issues).

To preform some tests, you could make a “test harness” program (a little program to hold your test code), which will just create certain objects and print out some memory information. Test harness programs are usually very short, with some basic code for your app pasted in, and a little control code.

First, the test harness would create 100,000 (or some other large number) of your standard objects, take the memory reading and store it/print it.

Immediately after that, the test harness would create 100,000 slightly different objects… (with extra/removed data elements, or extra/removed methods), and then store/print that.

If there are other aspects of the objects to check, the test harness would also exercise and measure those as well.

Once you have the results, you’ll have an idea of what aspect of the objects is eating up memory, and can devise an alternate strategy to manage those elements more efficiently. [import]uid: 79933 topic_id: 33064 reply_id: 131330[/import]

#6

Yes, that’s what i’ve been trying to do as well. Do you have any tips on how to print/debug from the terminal windows in corona?
It’s really hard to scroll up/down to see the dump prints and in windows i really cant scroll up to the 1st line.
[import]uid: 76697 topic_id: 33064 reply_id: 131338[/import]

#7

I’m using the mac, sorry. You could cut the amount of output to just a few critical things, or always print them last…

Maybe some windows user knows a way to expand the console buffer? [import]uid: 79933 topic_id: 33064 reply_id: 131340[/import]

#8

That’s okay, I’m on Mac as well but either way I wish there’s a better way to expand the terminal/debug console :slight_smile:
Btw, I was thinking about what you said : “like storing individual method pointers with the objects (possibly dozens per object), perhaps, as opposed to a single class method pointer to the entire classes methods (for example).”
I’m not sure I get this but I’m sure it’s me :)… Do you mind explaining abit about this problem? [import]uid: 76697 topic_id: 33064 reply_id: 131427[/import]

#9

In non-OO systems, your data might look like:

struct foo {
int x;
int y;
char myString[64];
};

If you make 1000 instances of the foo data, you would expect approx 68,000 bytes of memory to be used (depending on the size of an int in memory).

In an OO system, depending on the implementation, an object with the same data might have additional elements stored with it (generated by the language, not visible in your code), such as:

function *display
function *hide
function *translate
function *save
function *load
etc
etc

In the case of a lua implementation, instead of pointers, it may store strings (the function name string), which would make it take up even more room in each object than a pointer…

But this is the first lua implementation I’ve used (first time I’ve coded in lua), and haven’t run into this problem with my app (not using many objects).

If I had this problem, I’d make a test harness as described above, and generate a lot of my objects to see if they use a lot more memory than just the data itself would (to see if the object/method implementation had a lot of waste/overhead). [import]uid: 79933 topic_id: 33064 reply_id: 131432[/import]

#10

That’s okay, I’m on Mac as well but either way I wish there’s a better way to expand the terminal/debug console :slight_smile:
Btw, I was thinking about what you said : “like storing individual method pointers with the objects (possibly dozens per object), perhaps, as opposed to a single class method pointer to the entire classes methods (for example).”
I’m not sure I get this but I’m sure it’s me :)… Do you mind explaining abit about this problem? [import]uid: 76697 topic_id: 33064 reply_id: 131427[/import]

#11

In non-OO systems, your data might look like:

struct foo {
int x;
int y;
char myString[64];
};

If you make 1000 instances of the foo data, you would expect approx 68,000 bytes of memory to be used (depending on the size of an int in memory).

In an OO system, depending on the implementation, an object with the same data might have additional elements stored with it (generated by the language, not visible in your code), such as:

function *display
function *hide
function *translate
function *save
function *load
etc
etc

In the case of a lua implementation, instead of pointers, it may store strings (the function name string), which would make it take up even more room in each object than a pointer…

But this is the first lua implementation I’ve used (first time I’ve coded in lua), and haven’t run into this problem with my app (not using many objects).

If I had this problem, I’d make a test harness as described above, and generate a lot of my objects to see if they use a lot more memory than just the data itself would (to see if the object/method implementation had a lot of waste/overhead). [import]uid: 79933 topic_id: 33064 reply_id: 131432[/import]