Sign in to follow this  
BloodWarrior

Performance on declaring values as static on J2ME

Recommended Posts

Im not sure if I asked this before, I know I wanted to... since i cant find an answer here it goes: I got J2ME Game Programing by Martin J Wells and while it helped me quite a lot there are some questions regarding perfomance that bug me. The book says it better to declare as much as possible as static specially if we know we are only going to use a single instance of that class. Makes sense. If I only have one splash screen all encapsulated in a single class then if I declare as much as possible as static it will be initialised as soon as the class is loaded and the creation of the object itself should be quicker. Also since its static the processing of the method/member of the class should be quicker as it works straight from the class ignoring the instance itself. This looks all good and sound, though a bit weird. Any opinions/advices on this? My problem with it is that if I declare a sprite (for example) as static within a class then what happens when the class instance is no longer used? If I create an instance of splash which uses 2 or three images and then get rid of the instance I should free all the resources allocated to it. Since some of the resources are static then the code still keeps them into memory for as long as the class is loaded (always!). Am I right or something else is happening? Any thoughts Yours Truly K

Share this post


Link to post
Share on other sites
Quote:
Original post by BloodWarrior
If I create an instance of splash which uses 2 or three images and then get rid of the instance I should free all the resources allocated to it. Since some of the resources are static then the code still keeps them into memory for as long as the class is loaded (always!). Am I right or something else is happening?


Yes the resources will stay loaded. You can add a method to you splash class that frees it's resources.

All in all though, for something like a splash screen that only appears once at the beginning, optimization might not really be necessary.

shmoove

Share this post


Link to post
Share on other sites
Quote:
Original post by shmoove
All in all though, for something like a splash screen that only appears once at the beginning, optimization might not really be necessary.
shmoove


Yeah no biggie on the optimisation of the splash screen... but its just plain stupid to leave the image resources floating around when you are dealing with the rest of the game.

Also I was profiling it last night and noticed one thing that was bothering me... I cant seem to get rid of the last instance of my splash screen.

my code is roughly:

start
setcurrent displayable as new Splashscreen
when key press Slashscreen stops running and calls midlet to display something else
midlet setcurrent new displayable;

Technically there shouldnt be any reference to splashscreen but its still being held in memory (even pressing the gc button on the profiler).

I thought something was holding a reference to it so I changed the code that displays the new displayable to redisplay a new splash screen (creating a new splash each time i press a key).

The profiler now reports 2 (or more) splash screen instances but when I hit the gc button all but one of them are removed (even when something else is being displayed on scree).

For some reason there seems to be always a reference to the last created splash screen.

Does anyone know anything about it?
Its not that serious as I can simply write code that explicitly destroys the references to the any sprite/image/large class being held in memory for splash but it bothers me that its not being correctly deleted.

Yours Truly
K

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this