large Class.forName() patch

[Artur Biesiadowski]

Godmar Back wrote:
> 

> Even for runtime efficiency, you need to look at profiling data and
> decide whether it's worth it.  Is charAt() really the most frequent
> operation on java.lang.String?  For which application or set of
> applications?
> 

I had no time to implement full String using utf8, so I emulated slower
utf8 behaviour by adding loop for normal charAt, which traverses char
array from start to point of check, compares if it is greater than 127
and if yes assigns it to itself. Of course it is quite stupid opeartion
but I think it should be something in order of decoding utf8 (and same
as there there is only one 'if' and no more operations per character if
it is < 127). I don't suppose that working on bytes nor charater will
change speed here, so it should be good approximate.

I've changed only String.charAt - there will be more functions that need
to be changed possibly slowing it down further.

I've choosen quite String intensive application - I was compiling
SwingSet with kjc. Test was done under JDK 1.2v1 for linux with default
sun jit. With normal String kjc compiled everything in about 11 seconds
(measured by time command, user time - together with startup, dynamic
linking of libraries et all). With slower String it took slightly over
14.5 seconds.

As to how common is String.charAt - I've changed tya to count all
invokes and invokes to String.charAt at runtime. I've run SwingSet demo
and then clicked on every tab, but without meddling with components.
Ratio String.charAt/all calls was 309108/8611457. So about 3,5% of all
java calls in graphics heavy application is String.charAt. It is not
something to ignore - but making it considerably slower you impact all
java applications in visible manner - and remeber that it is with only
single method changed.


> Also, I think that charAt() can be sped up for "regular" strings
> that contain only ASCII chars < 127, because those can be represented in
> a byte array.  So you have to ask what strings you're application is
> dealing with.  That may depend on what i18n is used etc.

Yes, it will go faster as no decoding would have to be done for every
separate byte, but do you plan using special flag for marking such
Strings ? If not, you will have to traverse it one by one anyway. 

> I don't think one should rush to conclusions without data to back it up.
> It may or may not be a benefit, and most likely it will be sometimes.

No I had no data at time I wrote last mail and even currently I've done
only two small tests, but I have a general impression that String
performance is one of most important things for speed of java. I'm sure
I have reads few articles about it - unfortunately no links, so you can
suppose it is just my impression.


At last, I would like to agree with you that there are some ways in
which such implementation could perform better - memory usage, faster
copying and of course integration with internals of vm (which was a
reason for it in first place looking at this thread). If somebody
implements full String/StringBuffer class using utf8 we could perform
some real tests - what I'm trying to say is that speed of String,
especiall charAt is something to really care about - it is one of
hotspots for EVERY (or almost every:) java application.


Artur