Reports and "out of memory"

[dug9000]

Actually before you try large address aware, you might want to try setting the report settings in the offline result processor (Next to the processing configuration setting) to On-The-Fly and "Only Display Latest Results".

The offline result processor has separate settings than the sequence editor so you need to change these to minimize memory usage too for when you actually process the results.

-Doug

[j_dodek]

Hi Doug,

currently i have no Win7,64bit maschine with VisualStudio available (maybe next week).
I have tried your suggestion from prevoius post.
with out any success. It seems max Main-Loop count is 35 that allows to deserialise reports created by test_tsr.seq. (not everytime and also after system's restart, too.)

I have set some breakpoints in ReportGen_xxx.seq just to be quite sure that Parameters.Result is available and no resources from ReportGen_xxx.seq were used by TestStand.

In my opinion there is a need of a second SerializedResultsProcessor.Deserialise memberfunction that allows reading tsr. files blockwise or "sequence-call-wise". Once a block has been read and processed it should be removed from memory so we might avoid reaching the memorys
limits.

Just one question more. If you run SerializedResultsProcessor.Deserialise on your maschine what is your max loop count without any memory exception ?

Regards

Juergen

[dug9000]

Results are already serialized in chunks, that is why you don't run out of memory while serializing. I'm not sure why it can't also be deserialized and processed in chunks. You tried this directly with the offline result processing utility (not with APIs) correct?

-Doug

[j_dodek]

Hi Doug,

Yes, i did it with Processing Utility. I have disabled report generation in processing config, too. (see screenshoot1).

During processing the counter counts above 600.000 then it stops with error. (see screenshoot2).

Regards

Juergen

[dug9000]

I've reproduced the issue you are seeing and found out more details about it. Currently, even though the results are written in chunks, the offline result processor always reconstructs the entire result list tree before processing it, which, as you've seen, requires a lot of memory if you have a lot of results. In a future version of TestStand, this might be enhanced to support processing the results in chunks if the data was written in chunks (i.e. if on-the-fly is enabled - which is the default for offline). In the meantime, I'd recommend one of the following:

Either:

1) Don't use offline results processing, use ATML with "On-The-Fly", "Only Display Latest Results", and the model option "Discard results or Disable results when not required by model". I tried this with your example and it used only about 100 megs of memory. You might also want to modify the on-the-fly threshold settings in the advanced subdialog of the results processing dialog to improve performance.

Or:

2) If you still want to use the offline result processor for some other reason, you could try the large address aware changes I described earlier and see if that gives you enough memory for your use case.

Hope this helps,

-Doug

[Ben999_]

Another thing you might want to do is to limit the amount of results that are actually displayed in your report. If you disable result recording for all steps that you don't want to log, it will make your report substantially smaller. By default, TestStand logs each and every step, including all looping statements and structures which likely do not need to be logged. You might also be able to architect the test in some cases to report failure data only, for example with repeated digital patterns or simple pass/fail type results. Analog measurements might not be able to handled this way.