Re: speed of octave symbol table code

[John W. Eaton]

On 23-Oct-2007, David Bateman wrote:

| I think changing symtab.h:502 in the following manner for 3.0 will be a win.
| 
| -  symbol_table (unsigned int tab_s = 128,
| +  symbol_table (unsigned int tab_size = 32,

I thought about it some more and I think we should do a simple test
before making this change.  The thing I want to check is whether the
smaller table size results in significantly more hash collisions that
result in longer chains in the table.  If so, then although you are
speeding up some symbol table operations, you could be slowing symbol
lookups, which will affect the speed of evaluating the function
itself.  I think I can do this easily enough by modifying the clear
function to also write out a symbol table summary and then do a quick
test of a fairly large number of functions by running "make check" and
summarizing the results.  I'll try that and post the results.

| Yes, I'm waiting to see the advantages of the new symbol table code, if
| there are any speedups, etc..

My tests didn't show that it is much faster or slower, but it does
have the advantage of being (I think) easier to understand and the big
advantage of handling private functions, classes, and properly looking
up functions on the path before built-in functions.  I think it should
also make it easier to implement nested functions, but I haven't
actually tried to make that work yet.  One disadvantage is that it
relies heavily on function inlining and it is noticeably slower if
functions are not inlined by the compiler.

jwe