Multiple un-used Clone loaded in memory

[Darren]

These clone instances are being created when Open VI Reference is called with options x40 and x80, and they make up what is known as the Asynchronous Call Pool. This behavior is new to DQMH 5.0, since it is the first DQMH version that uses the Start Asynchronous Call function to launch cloneable instances. 

You can read the help topic linked above to learn more about the async call pool, and you can also take a look at this shipping example:

[LabVIEW 20xx]\examples\Application Control\VI Server\Asynchronous Call By Reference\Populating the Asynchronous Call Pool.vi

In short, what you are seeing is expected when using start async call... LabVIEW allocates some clone data spaces in the pool when Open VI Reference is called, which makes subsequent calls to Start Async Call be more efficient if there are free instances in the pool to grab. If for whatever reason you don't like those extra clones being allocated, you can use the Populate Asynchronous Call Pool method in VI Server to reduce the size of the pool. But I see no practical reason to do this.

[Eric_BOB]

Thanks, Darren
I did not know this technical point of the memory allocation pool for asynchronous calls. I just tried it out with the example and indeed the minimum pool size is 4. Exactly what I found during my DQMH5 tests.
So the question I'm asking myself is wouldn't it be useful to put the value of pool size as a parameter in the vi Start Module. This in order to pre-allocate this space according to the number of clones that we need. Especially if the clone is heavy on memory usage.
Anyway, thank you for this new knowledge that you brought to me. It was in the help, but it's always better to understand when encountering the problem than to read tons of documentation.

Eric

[Darren]

---

@Eric_BOB wrote:

So the question I'm asking myself is wouldn't it be useful to put the value of pool size as a parameter in the vi Start Module.

---

I think for the vast majority of DQMH users, letting LabVIEW manage the clone pool size will work just fine. I think for the very rare case where this might make sense for a DQMH project, that particular project can be modified as you describe (since all the VIs that would need modification are in the project, and not part of the shared DQMH libraries in vi.lib).

Nevertheless, if you think this should be considered more broadly, I suggest posting it to the DQMH Feature Requests forum.