Yep, the NASM 0.98 way of handling labels is not
optimal. In my local forked version I went to a
different design, which relies on dynamic memory
allocation, a flexible hash bucket count, and a
more suitable hash algorithm.
SF #893507: replace memory allocation in labels.c
SF #888518: add support for -H as well as ...
SF #900810: switch to Jenkins' hash to improve...
The fundamental idea is to reduce the number of
linear lookups, i.e. reduce the number of labels
per hash bucket, by increasing the number of hash
buckets, and employing a good hash algorithm, to
ensure nearly even distribution amongst buckets.
Worked out _really_ well for me. :)