Bug 28539 - Initializing of drivers takes long time
Initializing of drivers takes long time
Status: CLOSED FIXED
Product: qa
Classification: Unclassified
Component: Code
3.x
All All
: P1 (vote)
: TBD
Assigned To: Alexandre Iline
issues@qa
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2002-11-06 18:02 UTC by Marian Mirilovic
Modified: 2011-02-17 09:34 UTC (History)
0 users

See Also:
Issue Type: DEFECT
:


Attachments
test case (508 bytes, text/plain)
2002-11-06 18:03 UTC, Marian Mirilovic
Details
Sizes of packages and operators. (2.64 KB, text/plain)
2002-12-09 22:08 UTC, Alexandre Iline
Details
Code to measure initialization time (806 bytes, text/plain)
2002-12-09 22:10 UTC, Alexandre Iline
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marian Mirilovic 2002-11-06 18:02:34 UTC
[nb_dev](20021106) 

Try to run attached test case by Internal
Execution .
On my computer Solaris5.8,
MainWindowOperator.getFrame() takes more than 16
seconds !!!
So, in my opinion it is long time, it means each
test which uses Jelly spends 16 seconds on looking
for Main Window and it's really bad performance.
Comment 1 Marian Mirilovic 2002-11-06 18:03:44 UTC
Created attachment 7873 [details]
test case
Comment 2 Jiri Skrivanek 2002-11-07 08:33:34 UTC
I changed the summary because it is not problem of Jellytools but
Jemmy. Following test case takes long time as well:

        long start = System.currentTimeMillis();
        new JFrameOperator();
        long finish = System.currentTimeMillis();
        System.out.println("It takes ["+(finish-start)+" ms] !!!");

It is caused by initializing of jemmy drivers. For example, look at
org.netbeans.jemmy.drivers.focus.MouseFocusDriver constructor. A lot
of operators are loaded to memory by command AnOperator.class and it
takes a long time.
I think it is not necessary lo load all operators at this time. Shura,
is  it possible to change implementation to decrease initialization time?
Comment 3 Alexandre Iline 2002-12-09 22:06:38 UTC
First Jemmy call requiring Jemmy initialization causes almost all 
Jemmy classes loading. First of all it means that compiled classes
need to be loaded from filesystem, or an archive need to be
loaded and decompressed. Uncompressed compiled files take almost 
3 MB to store - no wonder it takes some time. Full list of packages
with sizes is attached.

This classes need to be loaded anyway - either during Jemmy 
initialization or during test execution one by one. Well, not all
of the classes need to be loaded, but most of them are. Like, for 
example, the biggest class is JTreeOperator (152 k), next 
going ComponenOperator (146 k) - they need to be loaded.

Class loading takes place once for one JVM (i.e. once for one 
testbag). If test extends JellyTestCase, initialization is 
performed during runBare() method execution - before testcase.

I do not clearly see what could be done here without full 
revriting of drives registrating, but even then - the only 
possible way I see - rewrite DriverManager so it would implement 
lazy initialization technique. But it woud mean endless "if/else 
if" statemens, an, in addition it's not clear how to work with 
"custom drivers".

Any ideas how to do it other way?

BTW, I've got interesting results: in my environment, Jemmy
initialization takes 3 sec when executed from commond line, 4 sec 
being executed from NB externally ans 23(!) sec - internally.
The testcase I use is also attached.



Interesting resutls: in my en
Comment 4 Alexandre Iline 2002-12-09 22:08:20 UTC
Created attachment 8247 [details]
Sizes of packages and operators.
Comment 5 Alexandre Iline 2002-12-09 22:10:13 UTC
Created attachment 8248 [details]
Code to measure initialization time
Comment 6 Jiri Skrivanek 2003-01-03 10:44:49 UTC
It is annoying especially when you developing a test case in IDE and
every start of jemmy test takes about 20 s.
If you will not rewrite drives registration, it would be better to
discuss (or file a bug) with guys from core why loading of classes by
internal execution is so slow.
Comment 7 Alexandre Iline 2003-01-04 02:20:12 UTC
Ok, I finally have an idea.

I can create another class - analogical to SupportiveDriver, but
working through reflection. It will be initialized by an
array of String - full names of supported classes.

Then, the check for an operator to be supported will be
performed by a comparision of those strings to a name of
an operator class and any its superclasses.

I'm starting this development.

Comment 8 Alexandre Iline 2003-02-22 03:01:10 UTC
Fixed in 2.2.0
Comment 9 Jiri Skrivanek 2003-02-24 09:33:10 UTC
Verified in 2.2.1. Thanks.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo