They’re probably implemented with hash tables. A large number of dynamic languages do that.
Static languages have the luxury of just packing all the data fields into a block of bytes and calling that the object.
Making good use of local variables is an optimisation that applies to all languages, dynamic or static.
Local variables will pretty much always end up in registers or on the stack.
Dynamic languages are typically stack based, but they don’t use the stack because that’s needed for VM function calls.
Instead they tend to maintain their own custom stack.
@Hanski , I am running into real issues with the garbage collector. It doesn’t work. No matter what I try to delete objects, they don’t get deleted fast enough, so the memory leaks kill me. I have to give up dynamic allocation completely
In particular, I am having issues reinitializing the game after player has died. I can’t for the life of me, get rid of old objects
If I, for example use a mechanism like this:
for i in range(0,6):
newpod = pod.Pods(x,y,z)
base.pods[i] = newpod
del newpod
… the newpod instances hardly ever get deleted, leading to running out of memory the next time. the base.pods are already static because of theses issues.
@dir3kt, I think I know now why you stopped on the Bearrrr project.
Quick update. Added my trick music idea (no SD needed).
The idea was to make it loud and noisy, and Ahti, my playtester, already enjoys the game. Music by me btw, made in LMMS
Pretty much only enemy ships missing now that memory issues are solved
Edit: why not original Bosconian sounds? Because I am going through all this effort, so why use someone elses copyrighted stuff. I am using milllisecond timer (inside Python) to loop and mix sounds
LMMS … I’ve got the full suite or FL Studio, but on linux it is much easier to just grab lmms haha… since I have to use Wine to get my fl studio working.
I found Bosconian themes on some online sequencer web app (google Bosconian music). I changed the note patterns to a different melody but with same key. I exported a midi, installed a .sf2 sound font for FM synthesis, played back from VLC to Audacity using Windows Wasapi as recording device. Put that as wav into LMMS and the rest is default instruments of LMMS
while(len(bases)):
object = bases.pop()
del object
gc.collect()
If not then you’re probably better off just deleting bases and assigning a new list to it.
If I had to guess, I’d suspect List is implemented as a reference to a block of memory and an index pointing to either the next item or the last item in the list, then pop is implemented by just decrementing the index rather than trying to remove the reference to the item.
This is why I haven’t been getting particularly involved with Python.
Dynamic languages always seem to be easier for people to use at first because they hide away all the details of memory allocation.
However, after a game gets to a certain size the memory starts to dry up and it’s really hard to figure out why precisely for the same reason the language is seemingly easier - because all the details of memory allocation are hidden away.
To compound the problem, dynamic languages tend to eat a lot more memory than statically typed languages because they rely heavily on dynamic allocation, whereas with statically typed languages you can typically avoid using dynamic allocation altogether, or at least keep better control over when it’s used.
In your case it could even be that you’re actually running into heap fragmentation issues depending on how the GC works.
(I.e. whether or not it uses an anti-fragmentation techniques like allocating object pools.)
Ultimately this is all just another example of one of the golden rules of programming: everything is a trade-off.
Python is easy to get going with for a beginner,
but on an embedded device you’ll hit the ceiling of capability much sooner.
C++ takes more time to understand and get used to,
but it gives very fine control over memory usage,
meaning that it can achieve a lot more than GCed languages.
However, a programmer’s understanding of the inner workings of a language always dictates how effectively they can conserve memory, regardless of language.
Indeed. And now that I have figured out (somewhat) how the garbage collect works, I am ready to admit I was wrong. The problem was my code, not the uPython gc.
There was one stage in the loading of the level where I appended to a list but forgot to pop. That was the memory leak.
Now, having figured that out and taking care of all my objects, I am running 50 mines, 50 asteroids, 35 pods, 5 bases and 20 projectiles at once, all dynamic instances.
I think uPython is handling it pretty nicely, given the tiny RAM its working with. My poor code was the culprit. Just so that I set the record straight.
… I’ve got the full suite or FL Studio, but on linux it is much easier to just grab lmms haha… since I have to use Wine to get my fl studio working.
Working on learning more though.