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
… 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.
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
object = bases.pop()
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.