How to free up memory while executing

[OnlyOne]

Hello,

i have a testplan which is excuting fine in normal runmode.

To debug a long-time-use i am calling one of the containing subsequenes 25 times.

All 5 repeats i set a breakpoint to check the used memory of seqedit_32.exe

Here is see now:

280.000 K at the beginning

645.000 K after 5 loops

1.023.000 K after 10 loops

1.406.000 K after 10 loops

1.786.000 K after 15 loops

2.160.000 K after 20 loops

At the end of the loops it is doing the cleanup steps and should normally start to display the report. But insted of this teststand crashes and shows a dialog box with "Teststand sequence editor is not working any more [close]"

What can i do to save memory?

I already set all not-limit-Tests to "Record Resuls = Disable".

When changing to run only two loops instead of 25 then the testplan is again finishing normal and shows after the loops 396.000 K used memory

While teststand is building up the report tab i see that the memory increases to 1.200.000 K

After closing the report tab the memory goes back to 340.000K

One loop is around 6000 result-steps

So it looks like a physical memory problem of the computer.

Then i disabled the report generation in the menu but the needed memory after 5 loops is the same as with enabled reporting.

What can be done to save memory?

Thanks

[bienieck]

This looks like an interesting problem to solve. Too bad that the question is 2 months old. Regardless of whether it was resolved or not I will put my two cents worth in here.

6000 result in one execution is quite a number!

I will suggest a couple of things to consider:

1. Sequence/steps dynamic loading. We can configure single steps or whole sequence file to load dynamically during execution and then unload if not used anymore. This can save some memory if you have numerous code modules loaded into the memory. If you call the same code all the time there will be no big benefit of using it. Messing with TestStand internal sequence cache with methods seems also to have no sense. But maybe it is worth considering to group some steps and allow better dynamic loading.
2. Result processing plugins configuration. I'm suggesting to remove all the plugin instances from the results processing configuration. So go to the Configure >> Result Processing and remove all the plugin instances from the list. Not only disable - remove it. This way you will still save some space. You will not have any result processor running after test execution. You may ask then how to get a report? I will come to this soon.
3. Result recording and ReultList. Go to Configure >> Station Options >> Execution Tab and disable result recording for all sequences. This way you could ensure to not create any Locals.ResultList entry. I believe that the ResultList is the thing that causing your problem. TestStand engine allocates memory for the ResultList entry for every step with result recording enabled. It is an engine thing. And single entry is not a single byte - it is a quite complex data structure. So, having 6000 results per test requires a lot of memory to allocate just for the ResultList. That's why I suggest to completely disable it.
4. Having all the default results recording disabled and also no result processor running you need to implement something custom. You can use engine post step callbacks or custom step types with some "post" functionality to get the result you need and send it to the database or save on the local hard drive. What you need here is custom on-the-fly reporting with no default ResultList.

Is this make sense to you?

[OnlyOne]

Thanks for your detailed answer:

1. I only have ~10 different teststeps.

2.If i set "Disable result recording in all steps" (your point 3) - then there should be no difference to disable the resut processing too, or? If there are no results then there is also nothing to process.(my thinking)

3.This is something i have to test but sound good.

4.I am already using a SequenceFilePostStep to get the results. In there is only a "UIMsgResult-Teststep. My custom GUI is listening to the messages and grabs the testresult using this message with RunState.Caller.

BUT: I wonder if this will still working if i disable the result-creation? Will there still be results attached to the RunState-Caller?

best regards

[bienieck]

Re. 2. You are right - If you disable result recording then result processing has noting to process, but it is still there and if I remember correctly it will be cached at the beginning of the process model entry point. So, just to save some extra memory, you can remove it all.

Re. 4. In the SequenceFilePostStep (or other PostStep callback) you can use Parameters.Step.Result variable to access latest result and do with it what you need (even if you have result recording disabled). Using RunState.Caller.Step.Result will give the same result.

I looked trough the list of UI messages and I don't see "UIMsgResult-Teststep". Is this a step name in which you send UIMsg_UserMessageBase? If so, then it should work.

[bienieck]

I found one more thing. Process model will not populate ResultList if Execution.DiscardResults is set to True. This one is set if you have only on-the-fly result processing plugins AND DiscardUnusedResults set in ModelOptions. But in your case you might still need some custom on-the-fly plugin. You can try default plugin with on-the-fly option enabled, anyway. To have it properly configured, remove other plugins (to be sure that results post processing is not needed).

• Discard Results or Disable Results when not Required by Model—Specifies if the process model discards results after the Post Result callback sequences execute when using on-the-fly report generation or database logging, or disables result collection for the execution when report generation and database logging are disabled. This option is available when you are using the Sequential, Parallel, or Batch process models.

  Note  If you have configured the process model to use multiple process model plug-ins, the process model discards or disables results only when you have configured all process model plug-ins to process results on-the-fly.