I just read the original thread.
Seems like this code is in question.
def assert_exists
locate if respond_to?(:locate)
unless ole_object
raise UnknownObjectException.new(
Watir::Exception.message_for_unable_to_locate(@how, @what))
end
Would changing it to this fix the performance problem?
def assert_exists
unless ole_object
locate if respond_to?(:locate)
end
unless ole_object
raise UnknownObjectException.new(
Watir::Exception.message_for_unable_to_locate(@how, @what))
end
On Mon, Aug 29, 2011 at 1:33 AM, Jarmo <[email protected]> wrote:
> I've already answered to that problem in the original thread at
> http://groups.google.com/group/watir-general/browse_thread/thread/9d5557820580249e
>
> I've also added some suggestions along the line of the same points as Ethan
> brought up.
>
> Jarmo
>
>
> On Sun, Aug 28, 2011 at 11:46 PM, Ethan <[email protected]> wrote:
>
>> I don't know why you're using class variables here. that's just wrong to
>> begin with.
>> it looks like this basically bypasses relocating in most circumstances.
>> this makes assert_exists do pretty much nothing.
>> that's fine in many circumstances, but it'll fail when things start
>> modifying the dom with javascript. the ole object will become invalid, and
>> should be relocated, but this bypasses that.
>> watir should be doing two things, I've found: be better about only
>> checking if an element needs relocating when operations have been performed
>> which may have modified the dom; and check if the ole object is in fact
>> still attached to the dom before trying to relocate.
>>
>> On Fri, Aug 26, 2011 at 10:31, Michalski Jerzy <[email protected]>wrote:
>>
>>>
>>> Following Zeljko's suggestion, I resume here the problem I presented in
>>> "Watir is slow with nested frames" thread of the Watir General group (*
>>> https://groups.google.com/forum/?pli=1#!topic/watir-general/nVVXggWAJJ4*<https://groups.google.com/forum/?pli=1#!topic/watir-general/nVVXggWAJJ4>
>>> ).
>>>
>>> I use Ruby 1.8.7, Watir 1.9.2, IE8
>>>
>>> Problem:
>>> When I execute an action on an element placed in a deeply nested frame,
>>> the method assert_exists from the Element class is called again and
>>> again by many methods, also by those called by assert_exists! As a result,
>>> for my simple example of 7 nested frames (see the thread "Watir is slow
>>> with nested frames" for details), this method was called 1536 times! The
>>> same elements were located again and again with exactly the same criteria
>>> (@how, @what and @container)!
>>>
>>> My solution
>>> I modified the method assert_exists by adding four class variables that
>>> store the three location criteria and the OLE object found. Next time when
>>> the method assert_exists is called, the new criteria are compared with the
>>> previous ones. If they are the same, no need to 'locate' again, simply
>>> return the object found previously. After my modification, the method
>>> assert_exists is called only 17 times (always with my simple example), and
>>> the real location is done only 8 times (7 frames and one text field) - other
>>> 9 calls return the previously located objects. And everything takes less
>>> than 1 second (compared to 15 seconds before!).
>>>
>>> Here is the modified method:
>>>
>>> def assert_exists
>>> if respond_to?(:locate)
>>> if (defined?(@@how) && defined?(@@what) && defined?(@@container)
>>> && defined?(@@o) &&
>>> @@how == @how && @@what == @what && @@container ==
>>> @container)
>>> # The element has already been located -> take the already
>>> located OLE object
>>> @o = @@o
>>> else
>>> # Locate the element...
>>> locate
>>> # ...and save the information that served to locate it...
>>> @@how = @how
>>> @@what = @what
>>> @@container = @container
>>> # ...and also the located OLE object.
>>> @@o = @o
>>> end
>>> end
>>> unless ole_object
>>> raise UnknownObjectException.new(
>>> Watir::Exception.message_for_unable_to_locate(@how,
>>> @what))
>>> end
>>> end
>>>
>>> Question:
>>> As I am new to Watir (and Ruby), maybe I have ommited an important
>>> functionnality that may be broken by my modification. Is there a downside
>>> to this?
>>>
>>> Jurek
>>> _Disclaimer
>>> Vaudoise.ch______________________________________________________________-_
>>> Le présent courriel, y compris les pièces jointes, s’adresse
>>> exclusivement à la (aux) personne(s) ou à la société à laquelle (auxquelles)
>>> il est destiné et peut comporter des informations confidentielles et/ou
>>> protégées par la loi. Toute divulgation, reproduction ou utilisation de ces
>>> informations est interdite et peut être illégale. Si vous n’êtes pas
>>> destinataire de ce courriel, merci de le détruire immédiatement et d’en
>>> aviser l’expéditeur.
>>> This e-mail, including attachments, is intended for the person(s) or
>>> company named and may contain confidential and/or legally privileged
>>> information. Unauthorized disclosure, copying or use of this information may
>>> be unlawful and is prohibited. If you are not the intended recipient, please
>>> delete this message and notify the sender.
>>>
>>> _______________________________________________
>>> Wtr-development mailing list
>>> [email protected]
>>> http://rubyforge.org/mailman/listinfo/wtr-development
>>>
>>
>>
>> _______________________________________________
>> Wtr-development mailing list
>> [email protected]
>> http://rubyforge.org/mailman/listinfo/wtr-development
>>
>
>
> _______________________________________________
> Wtr-development mailing list
> [email protected]
> http://rubyforge.org/mailman/listinfo/wtr-development
>
--
Bret Pettichord
Director, Watir Project, www.watir.com
Blog, www.testingwithvision.com
Twitter, www.twitter.com/bpettichord
_______________________________________________
Wtr-development mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/wtr-development
