This is an answer to an old mail from Artur, but this has never
changed since March.
On Mar 2, Artur Biesiadowski wrote:
> Here are few of my ideas about how some classes can be made a lot
> faster. Maybe I'll implement them, but if not I would like to share
> them.
>
> java.lang.Character
> I was already talking about it - work directly on array, without
> CharAttr creation (it is already done in my version) and create
> compression tables more loosely - do not compress blocks that are too
> short (like 2-5 lengths) - they should be merged with surrounding
> explicit info (for better preformance in findBlock)
I made a change that does this. It also uses Strings to get the
initial data, instead of using various java.io classes. I think it
might be bad if the static constructor of a basic class like
java.lang.Character uses too many other classes (this might lead to
bootstrapping problems). The strings are created by a perl script.
See: http://www.informatik.uni-oldenburg.de/~delwi/classpath/
Artur: You should test it for performance. It is probably slower if
many different methods are called on the same character (since I don't
have a cached CharAttr), but faster if they are called on similar
characters (characters in the same block). I think the normal case is
that someone parses a string or a file and invokes a few different
methods on many different (but often similar) characters.
> [a nice java.util.Hashtable idea]
> java.lang.BitSet
> It might be interesting to implement BitSet to use array of ints instead
> of array of longs. Of course sun have created API of bitset heavily
> based on their internal representation - but only serialization and
> hashcode computation would require hackery. Such BitSet would work a lot
> faster on 32-bit CPUs. I wonder if it would be possible/reasonable to
> distribute two versions - and place one that will work faster for target
> machine (of course both of them would work on every platform).
I already did this at that time, but never checked it in. Artur
reported that it gave a good speedup for 32-bit CPUs.
One problem with this file is that it needs a kind of preprocessor to
differ between 32-bit and 64-bit CPUs. I used some perl code that
automatically comments out one part of the file.
Jochen
