Re: New switch/case idea
- Posted by jimcbrown (admin) Apr 10, 2009
- 1655 views
You addressed the speed issue (which is probably pretty insignificant, I think we both agree),
I've tested the swithing and usual versions of that procedure,
init_opcodes(), and init_opcodes_my() - 10000 iterations on P4 1.8GHz:
<snip>
Usual one looks better - about 50% faster.
ex.exe tends to be faster on that task.
You can get my test program here:
http://www.private.peterlink.ru/kinz/test_switch.zip
kinz
Sorry, doesn't count. Your test program has a for loop for the operation[i] = routine_id(opName[i]), but then it stupidly uses the exact same for loop with the switch inside.
Also, the example uses strings, which are slower. If we were to switch on integers (such as in the do_exec() loop) then switch would speed up.
Finally, there is the effort involved in keeping all three sequences involved in sync. If opnames and opName had an off-by-one error (someone swapped two lines), we'd have problems. This is why the old version of the loop used find() instead of the parallel array technique.
switch is probably not as fast as the parallel array technique, but it is less error prone
but not the issue of the translator or binder knowing which routines are routine_id targets, and the benefits of being able to do that.
I do not know your plans. If you want to optimise the translator or binder some way, that procedure doesn't seem to be a good place for experiments with switch - it is too actual code.
The optimization to the translator and the binder is unrelated to the use of switch.
However, neither are experiments, rather they are definite improvements to the system.
