"Jochen Hoenicke" <[EMAIL PROTECTED]> writes:
> > 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
A possible configure solution is to place both files into CVS with
different names denoting 32bit/64bit and at configure time create a
symbolic link from the appropriate file to BitSet.java. In
classpath/lib/standard.omit put the two files for 32bit/64bit in the
list to be omitted (BitSet will still be picked up). See
AC_LINK_FILES in configure.in for an example of doing the link.
Although not my concern at the moment this method should do
file/directory copies on platforms not supporting symbolic linking and
if it doesn't it can be fixed to do just that.
I'm in the middle of heavily hacking lib/Makefile.am so you might want
to go ahead and do this yourself.
Brian
--
Brian Jones <[EMAIL PROTECTED]>
