performance of Class.forname()?
 

In a couple of performance articles, it is recommended to dynamically
load classes as needed with Class.forname().

Why?

Re: performance of Class.forname()?
 

On Sun, 20 Jul 2003 03:42:05 GMT, Ahmed Moustafa <amoustafa@pobox.com>
wrote or quoted :

>In a couple of performance articles, it is recommended to dynamically
>load classes as needed with Class.forname().

I can't think of a performance reason.

Java does not load classes until they are needed, whether or not you
use Class.forName.

The usual reason for using it is to allow plugin classes that are
created later.

For example, I use them in my HTMLMacro skeleton. You can add new
Macros written in Java without recompiling the macro expansion shell
engine.

I also use them in the Holiday Calculator. You can add more holidays
just by implementing an interface.

In static native compilation, Class.forName screws things up. New
classes come in out of the blue that were not present for global
optimisation at compile time.



--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

Re: performance of Class.forname()?
 

Lothar Kimmeringer wrote:
> On Sun, 20 Jul 2003 03:42:05 GMT, Ahmed Moustafa wrote:
>
>
>>In a couple of performance articles, it is recommended to dynamically
>>load classes as needed with Class.forname().
>>
>>Why?
>
>
> There should be a reason in the articles. IMHO it's better to
> initialize instances the "normal" way (using new) to be able
> to find errors during compile-time. A
>
> MyClass myClass = Class.forName("Myclass");
>
> will lead to a ClassNotFoundException during runtime. A
>
> MyCLass myClass = new Myclass()
>
> allows the compiler to tell you that there is no class with
> name Myclass.
>
> And I'm quite sure that you will lose more time in a
> constructor being implemented inefficently that you
> will get with using forName instead of new.
>
> Do you have a link to one of these "couple of" articles?

http://www.cs.utexas.edu/users/toktb...s.html#classes
http://patrick.net/jpt/

Re: performance of Class.forname()?
 

On Sun, 20 Jul 2003 15:29:02 GMT, Ahmed Moustafa <amoustafa@pobox.com>
wrote or quoted :

>http://patrick.net/jpt/

states:

"Unless a method is final, it is located on demand at runtime. Methods
are encoded in .class files as strings, not addresses. This allows
them to be relocated easily and makes overflow attacks harder, since
you don't know where any particular method is going to be. But this
also means a lot of runtime overhead of string parsing and method
location is going on at runtime, unlike C, where execution jumps
directly to the address compiled into the code."

This is misleading. It gives the impression that methods are linked
with some sort of hashtable on every call. Even in the most primitive
interpreted systems, methods links are converted to direct address
links on first call. This is partly why you can't easily replace class
files on the fly.
--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

Re: performance of Class.forname()?
 

On Sun, 20 Jul 2003 15:29:02 GMT, Ahmed Moustafa <amoustafa@pobox.com>
wrote or quoted :

>http://patrick.net/jpt/

I think the explanation is that "Patrick" has gleaned his knowledge by
pragramatic experiments and made some guesses as to how the JVM worked
inside, but did not check to see if he was correct. I think He
imagines that Class.forName will save RAM. He probably thinks that
all classes in the jar are loaded, whether they are used or not by the
ordinary mechanism.

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

Re: performance of Class.forname()?
 

"Ahmed Moustafa" <amoustafa@pobox.com> wrote:
> In a couple of performance articles, it is recommended to dynamically
> load classes as needed with Class.forname().
>
> Why?
>

Under normal operation, the JVM does not load classes into main memory until
they are needed, often in response to a call to the new operator. Delaying
class loading like this may result in a slowdown as the needed classes are
loaded (but only the first time they are needed).

I am guessing that the articles (without any references) say that using
Class.forName on the classes may avoid the dynamic loading that happens the
first time they are needed.


While this is true, I wouldn't recommend it unless you can prove two things:

1) Dynamicly loading classes as they are needed results in an unacceptable
slowdown,
2) Forcing the classes to load before they are needed with Class.forName
actually makes things better.

I wager that this is a tough test to meet. In my experience, many classes
are loaded long before I naively expect them to be: this is because the JVM
traces static class references in the entire class file as it is being
loaded and recursively loads all of the classes needed to resolve the
symbols. Additionally, the strategy of forcing classes to load with
Class.forName works only when there is a long delay between the time the
forced-load happens (often at startup) and the time the classes are actually
needed. The strategy is fragile: it relies on some list of classes that need
to be pre-loaded; that list needst to be generated and maintained if it is
to be of any use. And since the GC can unload classes if they don't have any
instances or active threads in any method, the strategy is likely to fail to
achieve its purpose anyway.


-- Adam Maass

Re: performance of Class.forname()?
 

Adam Maass wrote:
> "Ahmed Moustafa" <amoustafa@pobox.com> wrote:
>
>
> I wager that this is a tough test to meet. In my experience, many classes
> are loaded long before I naively expect them to be: this is because the JVM
> traces static class references in the entire class file as it is being
> loaded and recursively loads all of the classes needed to resolve the
> symbols. Additionally, the strategy of forcing classes to load with
> Class.forName works only when there is a long delay between the time the
> forced-load happens (often at startup) and the time the classes are actually
> needed. The strategy is fragile: it relies on some list of classes that need
> to be pre-loaded; that list needst to be generated and maintained if it is
> to be of any use. And since the GC can unload classes if they don't have any
> instances or active threads in any method, the strategy is likely to fail to
> achieve its purpose anyway.
>

The GC can only unload classes where the classloader for a class is
unreachable. This is a change from the early Java releases where GC did
unload individual classes. This was changed to avoid surprises from
changes in static fields (returning to their initial state).

Mark Thornton

Re: performance of Class.forname()?
 

> http://www.cs.utexas.edu/users/toktb...s.html#classes

includes:
> Classes/Interface
> * replace generic standard classes with faster implementations specific to application
> * create subclasses to override methods with faster versions
> * program using interfaces, so that actual structure can be easily swapped to improve performance
....
> * dynamically load class with Class.forname() (why? no reason given)

'No reason given'- but how else do you do the first three dynamically?

> String
>
> * use char[] array directly to create String rather than StringBuffer
> * convert string to char[] to process character, rather than using charAt()
Both require an array copy.

for (int k=0; k<10000; k++) {
for (int j=0; j<strings.length; j++) {
// converting to char array >>>>>
char[] data = strings[j].toCharArray();
for (int l=0; l<data.length; l++) {
really = really && data[l] == 'j';
}
}
}
runs in around 17ms where strings is an array of ten Strings of length 7.

for (int i=0; i<10; i++) {
start_time = System.currentTimeMillis();
for (int k=0; k<10000; k++) {
for (int j=0; j<strings.length; j++) {
String data = strings[j];
for (int l=0; l<data.length(); l++) {
// calling charAt >>>>>
really = really && data.charAt(l) == 'j';
}
}
}
runs in around 5ms with the same data (java 1.4.1_01-39 on OS X)


Pete

Re: performance of Class.forname()?
 

pete kirkham wrote:
>> http://www.cs.utexas.edu/users/toktb...s.html#classes
>>
>
>
> includes:
> > Classes/Interface
>
>> * replace generic standard classes with faster implementations
>> specific to application
>> * create subclasses to override methods with faster versions
>> * program using interfaces, so that actual structure can be easily
>> swapped to improve performance
>
> ...
>
>> * dynamically load class with Class.forname() (why? no reason given)
>
>
> 'No reason given'- but how else do you do the first three dynamically?
>

Hmmm... let me jump in here with no context and just try to hack some
answer...

OK. The first one is easy.

Document myDoc = new MyTunedForMyAppDoc();
JTextArea area = new JTextArea( myDoc );

Bingo!
:-)

Or
Document myDoc = new MyStupidButOnly16KDoc();

etc.

* the second:
Basically the same thing

Gee. And same on the third.


All three of those can be implemented through several standard patterns,
including factory methods and singletons. No class.forName() required.




> runs in around 17ms where strings is an array of ten Strings of length 7.

> runs in around 5ms with the same data (java 1.4.1_01-39 on OS X)

So the "optimized" version is more than 3 times slower on your machine?

Re: performance of Class.forname()?
 

Jon Skeet <skeet@pobox.com> wrote in message news:<MPG.1985c73fbe03e00498c2dc@dnews.peramon.com >...
> > I only has a dozen or so classes, but I dummied up a 100 string
> > comparisons and it was still faster than dynamic loading and
> > newInstance().
>
> Out of interest, which VM was that with? It'd be interesting to see the
> results on various VMs, as I believe 1.4 is significantly faster at
> this than 1.3.1.

This was on 1.3.1, but I've just installed 1.4.2 and will be
re-compiling this evening, I've still got the alternative code so I'll
post the results tomorrow.

- sarge