A hashed search array is a lot faster than search trees (trie).
Most likely yes. So long as the hash is cheap.
We need to scan for end-of-word anyway. So the cpu needs to fetch the data anyway, and just adding up (and maybe doing a bitshift) the values in a cpu register (assumes really good optimization) will not add much time (maybe even no time at all, since the cpu can use the time of the add, to pre-fetch the next bit of data)
So given how modern cpu work, yes a good hash implementation can be the fastest choice.
The trie needs to access more data, and the cost of fetching this, may be bigger than the cost of the hash+compare.
However computing a hash is slow, so unless you present a routine that combines all the operations (hash computation and searching) to give a working IsKeyword function there is nothing concrete to compare beyond opinions.
Yes, we are still missing any good comparison. So far we got a lot of impressive, but meaningless times.
And yes the final compare of the keyword must be done in the same function that did the hash (I wrote that before, but it was apparently ignored)