Namespace::lookupRecursive
by Tim McClarren · in Torque Game Engine · 11/29/2007 (2:37 pm) · 3 replies
Does anyone at Garage Games with some "institutional memory" know what this function is supposed to acheive?
Oddly, it's only called in one place, from Namescape::buildHashTable. That function goes through each Entry in the Namespace, gets the name of the entry, then calls Namespace::lookupRecursive on it with the name, which goes through all the Namespaces and Entries in the Namespaces to find the Entry and return it.
I can't for the life of me figure out the purpose of this.
Namespace::lookupRecursive never seems to return NULL (for our project).
Oddly, it's only called in one place, from Namescape::buildHashTable. That function goes through each Entry in the Namespace, gets the name of the entry, then calls Namespace::lookupRecursive on it with the name, which goes through all the Namespaces and Entries in the Namespaces to find the Entry and return it.
I can't for the life of me figure out the purpose of this.
Namespace::lookupRecursive never seems to return NULL (for our project).
About the author
#2
Namespace::find is called in several places including Namespace::activatePackage(), Namespace::deactivatePackage(), and the OP_FUNC_DECL/OP_CALLFUNC_RESOLVE cases in compiledEval.cc.
The global namespace is last in smNamespaceList. This means that every Namespace::find(NULL, NULL) call runs through all the namespaces before it realizes that it's looking for the global one. So you can add a check for this case and simply return smGlobalNamespace at the top of this function. You'll also have to change Namespace::init() to construct smGlobalNamespace itself because it is relying on find(NULL) to do it.
11/30/2007 (8:59 am)
That's an interesting find Tim. I don't know the full story here, but since you're getting down to this level there's another small optimization that may help you...Namespace::find is called in several places including Namespace::activatePackage(), Namespace::deactivatePackage(), and the OP_FUNC_DECL/OP_CALLFUNC_RESOLVE cases in compiledEval.cc.
The global namespace is last in smNamespaceList. This means that every Namespace::find(NULL, NULL) call runs through all the namespaces before it realizes that it's looking for the global one. So you can add a check for this case and simply return smGlobalNamespace at the top of this function. You'll also have to change Namespace::init() to construct smGlobalNamespace itself because it is relying on find(NULL) to do it.
#3
Now that I have a little bit better understand of consoleInternal.cc, it seems like there might be an achitectural change or two which would speed it up quite a bit.
11/30/2007 (2:10 pm)
Ah, yes, I had noticed that. I'll make that change too. I'm still doing some instrumentation in this code to try to understand it's run-time behavior better.Now that I have a little bit better understand of consoleInternal.cc, it seems like there might be an achitectural change or two which would speed it up quite a bit.
Tim McClarren
Default Studio Name
lookupRecursive seems to be there to try to ignore entries in the namespace that appear in some other namespace that takes precedence (?). If you don't have a lot of this, I'm not sure it's worth trying to save that 1-5% of the hash table. I'm gonna rip that out, just use the total number of entries in the namespace, and create the hash table with that size.
In addition, I just discovered that OP_FUNC_DECL (in compiledEval.cc) is really awfully expensive.
I think Namespace::unlinkPackages and Namespace::relinkPackages are used here for simplicity (rather than writing a Namespace::find, and a ns->addFunction that would do the right thing WRT current active packages, perhaps by passing that in as a param).
What that effectively means is that Namespace::buildHashTable gets called for out product ~26,000 times in the course of launching and exec'ing all the scripts.