Paul Fisher wrote:
[...]
> Things could be optimized to assume that once you've asked for data
> about a specific character, it's likely that you'll ask for more data
> on that same character. Such a change should incur a 20x performance
> increase for your test.
>
> Yet another option is to stick the entire Unicode attribute database
> into memory -- it's around 21k.
Now, there is no more file access at runtime and results are better, but
still very bad. Speedup for dropping file access was 3x, not 20x. My
test has changed, so here are updated results (all JDK1.1.5, Tya 1.2,
given in ms)
load run
JDK 4766 4435
old clpth 6775 148810
new clpth 5461 58755
So, instead of being 30x times slower it is 13x slower.
I still think that major penalty is creation of CharAttr for every
request. It is really overhead, as it is never reused. I think that if
all methods would access table directly and lookup only what is needed,
we could match JDK speed (be not more than 2x slower than them).
Artur
