Re: [abbot-users] [abbot - Developers] Costello slowing down

On Apr 23, 2008, at 4:25 AM, SourceForge.net wrote:

>
> Read and respond to this message at:
> https://sourceforge.net/forum/message.php?msg_id=4922509
> By: jvdp00
>
> Hello,
>
> I'm currently automating the insertion of assertions for a complete  
> dialog:
> basically I'm looking iteratively for all components in a dialog,  
> and for certain
> types (textfield, combo, checkbox, ...) I'm adding a couple of tests  
> automatically.
> It is already working fine, except for the fact that the process is  
> slowing
> down after a few dialogs. For a first dialog, it is very fast, say  
> 50 tests
> in a couple of seconds. For the next dialog it is still ok. For a  
> 3rd dialog
> I have to wait maybe one minute, and the time is further increasing
> exponentially.

Are the dialogs disposed after use, or are the resources kept around?   
Costello will dump its lookup maps which correspond to a disposed  
component.  It also optimizes lookups to prefer visible components to  
non-visible ones, but if you have several non-visible, undisposed  
dialogs, that may slow things down.

If you *do* keep undisposed dialogs, you might find things go faster  
by giving them explicit names via Component.setName.

>
>
> I have tried to find where the time goes to:
>
> - One problem was the automatic highlighting of the last inserted  
> test in the
> List. This step is not necessary since many other tests will be  
> inserted afterwards.
> I could exclude it by commenting the following lines in method  
> "addStep(Step
> step)" of ScriptEditor:
>        scriptTable.setRowSelectionInterval(row, row);
>        scriptTable.setCursorLocation(row + 1);
>        setActionsEnabledState();
> The same piece of code could be used after inserting all the tests.
>
> - The other problem that I cannot solve is somewhere in the stack of  
> method
> "getComponentReference(Component comp)" of ScriptEditor. This  
> function has to
> be called for each component for which an assertion will be added.  
> When digging
> into it I found out that most of the time goes to one method  
> "matchExisting(final
> Component comp, Collection existing)" of ComponentReference, and  
> more specifically
> in the following while loop:
>        while (iter.hasNext()) {
>            ComponentReference ref = (ComponentReference)iter.next();
>            if (comp ==  
> ref.getCachedLookup(ref.resolver.getHierarchy())
>                || comp == ref.resolveComponent(comp, empty)) {
>                matches.put(ref, Boolean.TRUE);
>            }
>        }
> It looks to me that some maps are rebuilt every time for each  
> component for
> which the reference has to be found, and this takes more and more  
> time because
> some maps get bigger and bigger when more and more dialogs are in use.
>
> I'm afraid that I know too little of the code to find a more  
> efficient way to
> get references for all the components in the dialog. Could there be  
> some procedure
> taking advantage of the fact that all components are in the same  
> hierarchy under
> the selected dialog, and that they do not change during the  
> insertion of the
> many tests?
>
The map lookups themselves don't take time, but checking the reference  
against the component hierarchy *does* take time (and is order N^2),  
which is why the results, both positive and negative, get cached.

Reference resolution should only happen once and thereafter use the  
cached value.  Negative cacheing gets cleared when something changes  
which might change whether a reference is found, e.g. window disposal  
or creation.

You can turn on logging of the ComponentReference class when you hit  
the bottleneck and see what's being looked up repeatedly.

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
abbot-users mailing list
[abbot-users@masked-domain]
https://lists.sourceforge.net/lists/listinfo/abbot-users