Regarding aliases, yes that'll be faster I believe because each of those variables inbetween the dots e.g. mytype.mytype2.mytype3 whatever can be flexible so it has to look at each of those pointers and jump to the next one - 3 pointers being accessed at least before getting to the end type, whereas a simple mytype=mytype2.mytype3.mytype4 takes you straight there.
I'm not sure if using locals and then passing them as parameters is faster than not passing anything. I guess it depends how BlitzMax might see that scenario and whether it optimizes it. If not, it probably copies them into a temporary variable, but maybe using Var will help? Never really tried that because I was more interested in not passing anything.
I make local copies of pretty much anything that gets accessed more than once.
Modern CPU's, not sure of the register count but it's a lot more than the 16 you'd get on the Amiga. Like maybe 32 or even 64. I do wonder also what happens when they run out, so where possible I still try to keep algorithms from being too big and complex.
Also arrays, or to put it another way memory access with pointers, is always going to be the fastest way, faster than any linked list of types. The only drawbacks are needing to preallocate/premeditate how much space you're going to need ahead of time, as a `chunk` of memory, what to do when you fill up that space, and how to add or remote/insert elements of data efficiently.
One method I came up with is to keep a counter of how many items are stored in the array. When you add an item you increase the counter. When you want to remove an item you subtract the counter and move whatever item is at the counter position (the end) and overwrite the item you're removing - it's sort of an automatic defragmentation. That works ok if your data doesnt need to stay sorted. Inserting can be done similarly by copying the item from the insertion position to the end and then overwriting it with the new item.
The main problem comes with resizing or running out of space. What I do actually is I made a linked list of arrays of objects, and then each item I want to refer to I do with a `link` pointer and an array index. It then ends up being two jumps to get to an item instead of one, but then you can transcend the boundaries of how much space is allocated. You simply add another chunk of space by adding on another link in the list containing a new array. When you get to the end of an array you just jump to the next link and the start of its array. This way you get some of the benefits of the expandability of linked lists plus the processing efficiency of being able to go through most items as an array. After all if your data is in the same sequence most of the time or the sequence doesn't matter there really is no point having the overhead of previous/next link pointers for every single item, and to have to go through them for every item you access.
I'm not sure if using locals and then passing them as parameters is faster than not passing anything. I guess it depends how BlitzMax might see that scenario and whether it optimizes it. If not, it probably copies them into a temporary variable, but maybe using Var will help? Never really tried that because I was more interested in not passing anything.
I make local copies of pretty much anything that gets accessed more than once.
Modern CPU's, not sure of the register count but it's a lot more than the 16 you'd get on the Amiga. Like maybe 32 or even 64. I do wonder also what happens when they run out, so where possible I still try to keep algorithms from being too big and complex.
Also arrays, or to put it another way memory access with pointers, is always going to be the fastest way, faster than any linked list of types. The only drawbacks are needing to preallocate/premeditate how much space you're going to need ahead of time, as a `chunk` of memory, what to do when you fill up that space, and how to add or remote/insert elements of data efficiently.
One method I came up with is to keep a counter of how many items are stored in the array. When you add an item you increase the counter. When you want to remove an item you subtract the counter and move whatever item is at the counter position (the end) and overwrite the item you're removing - it's sort of an automatic defragmentation. That works ok if your data doesnt need to stay sorted. Inserting can be done similarly by copying the item from the insertion position to the end and then overwriting it with the new item.
The main problem comes with resizing or running out of space. What I do actually is I made a linked list of arrays of objects, and then each item I want to refer to I do with a `link` pointer and an array index. It then ends up being two jumps to get to an item instead of one, but then you can transcend the boundaries of how much space is allocated. You simply add another chunk of space by adding on another link in the list containing a new array. When you get to the end of an array you just jump to the next link and the start of its array. This way you get some of the benefits of the expandability of linked lists plus the processing efficiency of being able to go through most items as an array. After all if your data is in the same sequence most of the time or the sequence doesn't matter there really is no point having the overhead of previous/next link pointers for every single item, and to have to go through them for every item you access.