Is it a bad idea to create a parser for an interpreted language using hashed tokens?

See more:

C++

parsing

interpreters

JIT

Fast version :
All is in the title.

Long version :

Context:
I am building an interpreted language in C++ and wanted to know what you think of a parser running using hashed strings.

Pros:
* Look-up in a table of hashed values (32 or 64bits) is way faster than in a string table ;
* Sweet switch statement with compile time string hashing ;
* The amount of characters in a programming language word (keyword, variable, function name) is quite low (depending on how you code) so collision should be rare (but this is only a guess).

Cons:
* A lot of hashing computation at lexer time ;
* Dealing with collision is not easy in multithreaded execution of the lexer.

These arguments gave me three choices if wish to implement a hashed parser:
1) Ignore collision and get crazy performances ;
2) Deal with collision with a high impact of performances ;
3) Detect collision (maybe only in debug build) and ask programmer to change the collided name.

Thank you for your time.

PS: If you have experience in parsing and want to share about that, I would be pleased to discuss with you !

What I have tried:

I already implemented a hashing parser but without collision check (and no multithreading).
I never encountered a hash collision using it but I didn't tested a lot of input text data.