I have a quite large test plan (~3000 steps) that is broken up into multiple .TapPlan files that are included in a top level test plan using a ‘Test Plan Reference’.
This loads and runs fine using TUI with no delays in opening the test plan.
The end user of this test plan wants to run on Linux but would prefer to use something like Editor to run the tests, so I have been testing using EditorX with community license.
The test plan runs fine, but it takes >1 minute to open the test plan, and this same delay occurs if I add or attempt to move a step. This makes it pretty impractical to use as a test editor with my large top level test.
Could this be related to the community license which reports usage statistics for the tests or perhaps something to do with cross platform gui (Electron? ). I’m wondering if this same delay be present if the end user is using a KS8400 license without usage monitoring?
So far, I have not seen the same delays under Editor CE on windows, but currently some of my plugins are Linux specific so can’t currently load and run the same test plan on Windows.
If anyone is using EditorX, I would love to hear about experiences with large test plans.
Thanks
1 Like
Hi @wittrock, thanks for the notification.
I can reproduce this issue. I will notify the team working on this and post an update when it is resolved.
Great!
Thanks for looking into this Rolf
Hi @wittrock,
I am pleased to announce that a release candidate of the fixed Editor X application is available.
You can install it this way: tap package install "Editor X" --version rc
In my testing the performance has been improved a lot.
Please try it out and let us know if you have any feedback.
1 Like
Hello Rolf,
Thanks for the update.
I did a quick test with my large test plan.
With version 1.5.0, the load time is ~90 seconds.
With version 1.6.0-rc, the load time is ~45 seconds.
So the rc cuts load time in half which is great.
Is there anything that I can do on my end to reduce load time further (short of reducing the number of test steps)?
Thanks again,
Ok, so in my testing the improvement was better than that. From 10minutes to 10sec or so.
Can you confirm that the exact version of Editor X you have now installed is 1.6.0-rc.2+0972d0f5?
Hello Rolf,
I verified I am using 1.6.0-rc.2+0972d0f5.
The test plan I am using is making use of many ‘Test Plan References’ to pull in sub test plans.
I am also making a lot of use of test step outputs linked to other step inputs. Without knowing the details of what causes the long load time, I am not sure if either of those can exasperate things.
I can put together another simple, but large test to see if I still see the long load time.
Thanks,
Quick update.
I created a simple test plan with ~3000 steps. This test plan is not using any external test plan references or test step output->input links. I found the load time is still ~40 seconds using EditorX 1.6.0-rc.2+0972d0f5, and OpenTAP Engine 9.21.1+2a94acc7.
So I don’t think the problem I am seeing is related to my specific test plan right now.
Thanks,
Ok, got it. Thanks for trying it out!
In my latest testing I thought I saw a larger improvement than that, but I guess it needs a bit more work on this front after all.
I will cycle it back to the team.
I am having a new problem which I am not sure is related to updating to 1.1.6-rc, but did not see it before.
I reverted back to 1.5.0, but am now still seeing the problem so, again, I’m not sure it is related.
I started a new thread here: Editor X hanging at end of test
I just installed the latest EditorX (1.6.0+d7917509 ), and it looks like I am still having a problem with very long load times for test plans as compared to TUI.
With the test plan as described previously, It currently takes ~60seconds to load the test plan.
Is there anything in particular I could avoid in the test plan that would improve the load time?
As mentioned previously, I am making use of many ‘Test Plan Reference’ steps to pull in other test plans.
I am partly doing this because the long load time is making it impractical to make changes in a very large test plan. So I’m having to break the Test Plan up so I can edit the individual parts without incurring the long delay each time a change is made.
Thanks for any insight into what I can do on my end to reduce the load time.
@wittrock We’ve made a huge performance improvement regarding loading large test plan in the upcoming release, along with bug fixes. Keep a lookout for it. 
@khang-yong
Thanks for the update. I’m looking forward to trying the next release.
In the mean time, I have found I can improve things quite a bit by using sweep parameter steps to reduce the total number of steps in the test plan (e.g. sweep over gain x1,x2,x4,x8 etc. instead of a seperate step for each).
I originally avoiding doing it this way because it is convenient for the end user running the test plan to see the individual step pass fail status. With the parameter sweep I loose some of that visual clarity but the final output captured by the result listener can show the individual line items so it is just an inconvenience during the run only.
Thanks,
Wittrock
1 Like