Changing to OOP, loosing performance?

Questions about the LÖVE API, installing LÖVE and other support related questions go here.
Forum rules
Before you make a thread asking for help, read this.
Post Reply
User avatar
Wiwiums
Prole
Posts: 9
Joined: Tue Aug 12, 2014 8:52 am

Changing to OOP, loosing performance?

Post by Wiwiums »

Helllllloooooooow!~
Yay first post~
Billionth visit to these forums, but first time requesting help.
I've been using love on and off for a few months now and i think its totally great!

So in my semester holidays i was playing around and decided to actually make a game, which I did, which was very poorly coded and thrown together and was a bit of a mess, but seemed to run fine.

It got to a point and i decided to re-write it with better practices (like no globals~) in OOP style.

So anyway this game is just like a sort of farm simulator i guess, like, plant things, let them grow, then pick the fruit and sell on a market (which adjusts price randomly and depending on what was sold).

So to make it more OOP i made objects for everything which was fine and cool, however, after not even doing much i noticed that the performance was pretty terrible/not as good! (I am using zerobrane studio package thing which i feel has a bit of overhead anyway)

So i'm just wondering whether the new implementation is very inefficient in design, or whether having lots of instances makes it slow, or whether my OOP closures is slow, etc.

Don't worry about the first file's code, its all terrible!

From tests i think its from having the drawing methods in their own object, but im not sure why that makes it slow?

I'd also be happy to hear cool recommendations~
Yay~

I've attached the code for the first method, and the second slower OOP method.
Click and drag to pan the screen, and Right click on the second game to pan.

Wiwiums~
Fastgame.love
first method:
(1.03 MiB) Downloaded 187 times
SlowGame.love
Second method:
(1.03 MiB) Downloaded 181 times
Pewpew
User avatar
Plu
Inner party member
Posts: 722
Joined: Fri Mar 15, 2013 9:36 pm

Re: Changing to OOP, loosing performance?

Post by Plu »

I don't have time to really dive in at this time, but in general the performance loss from changing to OO is either zero, negligable, or your performance will even go up from doing it.

So I'm guessing you've implemented something poorly and that's causing the problem. Unless someone else chimes in today I'll have a look when I get home from work tonight :)
User avatar
Wiwiums
Prole
Posts: 9
Joined: Tue Aug 12, 2014 8:52 am

Re: Changing to OOP, loosing performance?

Post by Wiwiums »

Haha thanks!
I was expecting the performance to increase if anything, as i had a lot of globals floating around; so it was probably some terrible implementation on my behalf.
Thanks again~
Pewpew
davisdude
Party member
Posts: 1154
Joined: Sun Apr 28, 2013 3:29 am
Location: North Carolina

Re: Changing to OOP, loosing performance?

Post by davisdude »

i.import tiles is being called in love.draw. Based off of the name of the function, that should be in love.draw. I didn't spend a ton of time looking though, so that may not be the problem.
GitHub | MLib - Math and shape intersections library | Walt - Animation library | Brady - Camera library with parallax scrolling | Vim-love-docs - Help files and syntax coloring for Vim
User avatar
Wiwiums
Prole
Posts: 9
Joined: Tue Aug 12, 2014 8:52 am

Re: Changing to OOP, loosing performance?

Post by Wiwiums »

Ohh wow okay that is probably it, i cant believe i actually did that.
i gather you meant to say love.load?
Man, i thought the issue was a whole lot deeper than that haha; but ill change it when i get home.
thanks guys!
Pewpew
davisdude
Party member
Posts: 1154
Joined: Sun Apr 28, 2013 3:29 am
Location: North Carolina

Re: Changing to OOP, loosing performance?

Post by davisdude »

Yeah, I meant love.load.
Hope that fixes the problem. :)
GitHub | MLib - Math and shape intersections library | Walt - Animation library | Brady - Camera library with parallax scrolling | Vim-love-docs - Help files and syntax coloring for Vim
User avatar
rmcode
Party member
Posts: 454
Joined: Tue Jul 15, 2014 12:04 pm
Location: Germany
Contact:

Re: Changing to OOP, loosing performance?

Post by rmcode »

I think I've found the problem. It seems to be the garbage collector.

Place this in interface.lua to see it yourself.

Code: Select all

  function self.get_text()
    text = "MEM: " .. collectgarbage("count")
    return text
  end
This is just a guess, but maybe you are creating lots of throwaway tables. That's the first thing I would check. Oftentimes you can use the same table (especially with the correct use of OOP) for the whole lifetime of the object, instead of disposing of and recreating it on each update.

I also didn't have the time to take a closer look at your code, so I'm not sure what OOP approach you are using. I can recommend the closure based approach:

http://lua-users.org/wiki/ObjectOrienta ... reApproach
User avatar
Wiwiums
Prole
Posts: 9
Joined: Tue Aug 12, 2014 8:52 am

Re: Changing to OOP, loosing performance?

Post by Wiwiums »

Thanks guys!
davisdude had the right idea, that i accidentally put the 'import_tiles" function under love.draw, which of course was the function that imported all the different tiles i had, which was obviously hugely inefficient. Having moved that up it runs absolutely fine!
It seems really silly to do that, i was trying to find out the problem for a while and i guess i just didn't notice it :/

@rmcode the text displayed i assume is some sort of representation of the amount of garbage collected, and it just seems to be going up by like 10 a second...but i have no idea if that is good or bad!~

I am using the closure based approach, as i had a look at the 'normal' and i thought the syntax was...odd.
My only prior programming knowledge comes from python, c and a fair bit of java, and i preferred the closure based stuff, just made more sense to me; but good to see other people use and support it!~

Thanks for all the help so far guys!
Pewpew
User avatar
rmcode
Party member
Posts: 454
Joined: Tue Jul 15, 2014 12:04 pm
Location: Germany
Contact:

Re: Changing to OOP, loosing performance?

Post by rmcode »

Wiwiums wrote:Thanks guys!
davisdude had the right idea, that i accidentally put the 'import_tiles" function under love.draw, which of course was the function that imported all the different tiles i had, which was obviously hugely inefficient. Having moved that up it runs absolutely fine!
It seems really silly to do that, i was trying to find out the problem for a while and i guess i just didn't notice it :/

@rmcode the text displayed i assume is some sort of representation of the amount of garbage collected, and it just seems to be going up by like 10 a second...but i have no idea if that is good or bad!~

I am using the closure based approach, as i had a look at the 'normal' and i thought the syntax was...odd.
My only prior programming knowledge comes from python, c and a fair bit of java, and i preferred the closure based stuff, just made more sense to me; but good to see other people use and support it!~

Thanks for all the help so far guys!
Hm the memory was going up for me pretty fast (from 1000 to 2000 in 1 or 2 seconds). It was just a wild guess :)

Glad you managed to fix it though. I love the isometric style!
User avatar
Wiwiums
Prole
Posts: 9
Joined: Tue Aug 12, 2014 8:52 am

Re: Changing to OOP, loosing performance?

Post by Wiwiums »

rmcode wrote:
Hm the memory was going up for me pretty fast (from 1000 to 2000 in 1 or 2 seconds). It was just a wild guess :)

Glad you managed to fix it though. I love the isometric style!
Ohh i guess i only did this after i changed the point at which i imported the tiles hehe, so i guess 90% of the workload was removed.

Thanks for the support guys, the isometric maths was a bit of a hurdle but works super well now that i understand it :P

If you guys have any other recommendations on ways to improve my code i'd be glad to hear them!
Thanks once again peoples~
:D
Pewpew
Post Reply

Who is online

Users browsing this forum: Google [Bot], Semrush [Bot] and 6 guests