Le 23/07/2015 16:29, Richard Heck a écrit :
I wonder how bad this will be. In practice, people do not actually use
that many different words when writing. Probably no more than a few
hundred, and a couple thousand, at most.
It is not a problem of words, it is a problem of lines of text. For
example, for displaying this previous sentence while typing it, I have
to evaluate the length of
I
It
It_
It i
It is
It is_
It is n
[... lots of entries ...]]
It is not a problem of words, it is a problem of lines of te
It is not a problem of words, it is a problem of lines of tex
It is not a problem of words, it is a problem of lines of text
It is not a problem of words, it is a problem of lines of text.
These strings will remain forever in the map, and I will never need them
anymore.
Use of a hash, as you suggested
earlier, would probably be sufficient. I gather you just need to
implement qHash(docstring), as said in the FIXME, but that could be as
easy as:
uint qHash(const & docstring d) { return qHash(toqstr(d)); }
Strangely enough, I tried to do this, but the compiler never accepted to
link. I finally gave up and used a hash on QString instead. This is not
has good since the docstring->QString has to be done every time.
However, my approximate profiling with Instruments showed that, while
with current code display cost it 60% painting and 40% metrics, with
QCache<QString> the cost i more like 50%/50%, so that metrics
computation is less efficient.
I suspect that computing hash on long strings is less efficient than
sorting them in a map.
There is code floating around for having a map with an additional list
that orders entries. It is not so complicated to use, but my time is
running out right now.
JMarc
