This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
| Summary: | Initializing of drivers takes long time | ||
|---|---|---|---|
| Product: | qa | Reporter: | Marian Mirilovic <mmirilovic> |
| Component: | Code | Assignee: | Alexandre Iline <shura> |
| Status: | CLOSED FIXED | ||
| Severity: | blocker | ||
| Priority: | P1 | ||
| Version: | 3.x | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Attachments: |
test case
Sizes of packages and operators. Code to measure initialization time |
||
|
Description
Marian Mirilovic
2002-11-06 18:02:34 UTC
Created attachment 7873 [details]
test case
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?
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 Created attachment 8247 [details]
Sizes of packages and operators.
Created attachment 8248 [details]
Code to measure initialization time
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. 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. Fixed in 2.2.0 Verified in 2.2.1. Thanks. |