Le mercredi 31 août 2011 18:52:56 UTC+2, Jarmo Pertman a écrit : > > On Aug 29, 6:47 pm, JMI <[email protected]> wrote: > > > Anyway, i looked at the code and saw that everything that can be done > > > is already done. > > > > I am not so pessimistic. > > Thanks for not being! Your letter made me to look into it once again > and this time i paid more attention to code execution points and > noticed that there was indeed a bottleneck. In locator.rb in > FrameLocator there were these lines: > frames = @container.document.frames > @container.document.getElementsByTagName(tag).each do |ole_object| > > @container.document went up in the @container's chain calling > assert_exists each time so it was done quite many times as you said. > I've now added a cache for @container.document during the time of > locating the element which speeds up your example in a magnitude of 10 > times or more and the cache will be invalidated as soon as the element > has been located so there's not much of a danger of the cache being > out of sync. > > The fix is in this commit (there's also some other refactorings > involved) > https://github.com/bret/watir/commit/7ba7272b258005b0711fad61a7669632b05151e8 > The lines you should be interested in are 6-8 and 118, 120 in > locator.rb. Try it out and let me know of your results.
Just great! Now (with Watir 2.0.1 and your corrections) the number of calls to assert_exists increases linearly with the number of frames - before (with Watir 1.8.7) it increased exponentially, as 2**n. For 7 nested frames of my simple example it means a factor of about 12. > > > In conclusion, i'd still say that the application which uses 7 nested > > > (!!!!) frames is really badly made and should be rewritten anyway. No > > > offence. > > > > No offence! I have already said it is not me who created the application! > > > I'm still not changing my opinion on that thing. If the application is > not done by you then maybe you can talk to the persons who did that? > The application is owned by a big IT company (some tens of thousands of people world wide) and it is customized for nearly a hundred of client companies (also world wide). Some 100 people work directly for the development and improvement of the application (for already some 20 years!) and some other hundreds for customizations. The structure of the web pages is deeply influenced by choices made some 15 years ago and we will have to live with them for some another couple of years. The frames were a performance problem a time ago (pages loaded slowly) but it was solved by dynamically loading only the modified frames (usually deep in the hierarchy). Actually the only problem with frames I know of is that of Watir - but - Hey! - you have just solved it! Yes, I will talk about "that thing", but I will not put much of my energy into it! Nobody would want to change the GUI "just to modernize", with no other added value for the business. > If i'd have to test an application like that i'd really consider > changing my employer or projects :) Just a hint that life shouldn't be > too hard. I do not test "the application" - we only test on-site customisations. Some years ago I created a key-word driven framework that uses a commercial test tool to interact with GUI (no problem with frames). Now the commercial tool evolves into a big you-do-not-have-to-know-how-to-code monster and I am thinking of migrating my framework into Ruby Watir. This is my personal spare-time project. So life is not too hard! Thanks again, Jarmo! Jurek -- Before posting, please read http://watir.com/support. In short: search before you ask, be nice. [email protected] http://groups.google.com/group/watir-general [email protected]
