|
If you were logged in you would be able to see more operations.
|
|
|
|
Original Estimate:
|
Unknown
|
Remaining Estimate:
|
Unknown
|
Time Spent:
|
Unknown
|
|
|
Performance drops off progressively for an when users are sending JavaScript statements up using getEval (etc) and/or they are doing many instructions to selenium between open() invocations. This is as the result of a recent commit to the former 'last four commands' list.
open() flushes the last command buffer. In the above use cases, the buffer gets too big and the cost of javascript string concatenation is too high.
Given this was worse performance than before, the Selenium team should try to make it better. Indeed, it should be possible to go beyond the performance for this feature, but somehow optionally setting it to zero command listed as history.
Keith's proposal is that this could be a flag.
Dan has already applied a patch to limit lines to 70 chars in width, but nothing has been done about the number of lines in the list yet. Dan's patch is not part of a release. Nor is the bug for that matter.
(Reworded by Paul)
|
|
Description
|
Performance drops off progressively for an when users are sending JavaScript statements up using getEval (etc) and/or they are doing many instructions to selenium between open() invocations. This is as the result of a recent commit to the former 'last four commands' list.
open() flushes the last command buffer. In the above use cases, the buffer gets too big and the cost of javascript string concatenation is too high.
Given this was worse performance than before, the Selenium team should try to make it better. Indeed, it should be possible to go beyond the performance for this feature, but somehow optionally setting it to zero command listed as history.
Keith's proposal is that this could be a flag.
Dan has already applied a patch to limit lines to 70 chars in width, but nothing has been done about the number of lines in the list yet. Dan's patch is not part of a release. Nor is the bug for that matter.
(Reworded by Paul) |
Show » |
|
New Feature
Open
Major
Provide flag to disable command list
Specifically, a command-line option is fine for setting a default behavior for all successive tests.
There should be a way for a test, in its startup environment, to specify what it wants. In case one of my tests was going to run on an RC server that was started without the flag, I'd want to be able to programmatically ensure that the history was not displayed.
You may say "what startup environment"? I've stated previously that several command-line flags should be moved to the test's control, and so far all of these are things that would be set during the start() -- using something like start(TestConfiguration... config) (the vararg is primarily for compatibility with no-arg start commands which are right now *all* of them).
Furthermore (as current primary developer for the Google Selenium Farm) it would be very useful if I could just query the entire command history from the RC server instead of tracking those commands myself as they pass between user and RC server. Moving the command history storage into RC could have other benefits -- StringBuilder for efficiency and dereferencing on CommandQueue cleanup. At that point, a test wouldn't just have to choose between showing all or none of the command history, but could even set the command history to be shown to a limit of XXX chars or thereabouts.
Selenium Farm users have a definite need for the entire command history, but it's true that it doesn't not need to be visible unless someone is actually watching the test run. Showing it is similar to using the Core setSpeed to make sure that the commands go by 'slow enough', which is great for demos, and not for throughput. I would not call this usage trivial, nor a marketing gimmick, but it does have its place and time and being able to control it on a per-test and a per-RC level would certainly be beneficial.