I've begun to poke around in VCCore to speed up vergec execution. As an initial step I've inlined the Chunk::GrabXXX functions. This speeds up vergec execution, it would seem, by between 7-14%. It appears that the operation of vergec is the same (haven't found any problems). So doing such can basically give us a free 10% boost in execution speed.

Both ProcessOperand and ResolveOperand are called... a lot... and so are the next best candidates for optimization. I'm looking into how they can be sped up.

Also, it seems variables are accessed by looking up their variable name in an array via linear crawl. That's not terribly efficient. Some sort of sorting, key, or binary tree needs to be used. Preferably variables should be accessed via integer offset into the variables array. This would necessitate a change to the verge compiler as well (as far as I can tell.) It looks like functions are already usually being accessed by number instead of name (sometimes they are not such as when the autoexec function needs to be looked up but the majority of cases are not like that).

Does anyone else have any suggestions for vergec speedup?

Your first sentence is essentially what I am suggesting we do. There would be an array that holds the contents of each variable and an array that holds the name of each variable. Both arrays the same dimension. Then you just use array lookups to access the variable and if you need the name of it or you really do need to access a variable by name, then you can use the second array. BTW, I didnt mention it above but each variable type has it's own pair of arrays.

Variables should NOT be able to expand. If it's an integer then it should stay that way. If it's a 20 element array then it stays that way, etc. That drastically simplifies things. Unless I dont understand what you mean?

Binary trees are LESS efficient than direct array accesses. The reason for using them is that sometimes you dont know the integer value of the array index to access a certain variable. If you dont know the index then you need to find it. Binary trees can help with that. In general a balanced BST can find an element in O(log2(n)) tries. That is where log2 is understood to be log base 2. It takes on average 14 searches w/ BST to find the correct variable out of 10000 and it takes 10000 searches by doing it with just a straight element by element comparision (which is what verge does now). However, it takes 1 try to get the correct element if you already know the array index. As such BST's are great in compilers which are compiling a list of variables and must constantly correlate name to index. But once that it done you will be left with all index #'s and those can just be directly looked up.

So, BST (binary search tree) can be used in the compiler of vergec and direct access in the interpreter.

Why would the number of variables change at runtime? Does vergec really support dynamic allocation of variables? Seems like otherwise you'd know the exact # of variables beforehand.

Well Maps can have their own arrays for variables and that would negate any need to have a variable # of variables (heh).

By DMA, does that mean direct memory access, as in - verge can directly access the main memory of the machine (in a certain area anyway)? If so that might have to stay unoptimized but it should only be a very small part of most programs.