I modified a bit FASM version 1.65.25, to improve its speed (the main interest for me was to getting used to ASM again). The file enclosed with this post includes the list of modifications and the two modified files. Basically I changed a few linear searches into logarithmic (dichotomic) searches.
I know my code is poor - I mostly use C++ at work, and haven't used ASM for about many years...- but it works.
I post it here so that other users can benefit from my modifications. FASM is already fast, so it is not fundamental here, but I also wanted to point out the importance of the choice of the data structures. So many people forget that the time complexity of the algorithms is more important than the choice between high and low-level languages! A C++ program can be much faster than an equivalent assembly language program if the data-structures and the algorithms are not carefully chosen.
I would also like to ask an unrelated question: has anybody used FASM to produce code for a c/c++ project (gcc or visual C++)? A sample toy program would be welcome.

The keyword tables are of constant length and not very large, so their impact on speed never was as noticeable as with the compilation-time defined symbols - where I concentrated on designing some decent algorithms. If I wanted to optimize this, I'd perhaps go for the tree searching algorithm, like it was in my first assembler (see this thread), but I just always found something more interesting to do with fasm.

And, BTW, the "get_instruction" is not altered here, perhaps you posted the wrong version?

Yes, I posted the wrong version (an intermediate version with only the modifications on get_symbol, which make almost no difference. The speed up is higher with the instructions). I know the speed is not critical here, and there are much more useful things to be done... Anyway, as I mentionned in my post, this was more an exercise for me than a need.

Just for the fun of it - my most "aggressive" tree searching solution (char-ramified one, as opposed to the bit-ramified, thus binary, tree that is used for user-defined symbols hashtable in fasm). It eats almost a megabyte* of memory for set-up, but when scanning about million instructions it gives a huge speedup even on fast machines.
It involves changes in PARSER.INC only (the unaltered table format is just converted at parser's startup into a huge tree structure), and adding a double word "instruction_tree" variable to the VARIABLE.INC file. Enjoy!

* Actually it could be made to use about 1/4 of this, but I leave it as an excercise.