More control over deleting compile cache

[Intaris]

I'd like sometimes to have more control over what to delete from the compiled cache.

If I am working on a certain project and I'm having trouble with RT deploys and inlined VI code change propagation (it's a real thing) then I have found out that deleting the compiled code cache can help a lot.  Thing is, I don't really want to delete all of the cache, only those related to a sub-set (current project / directory on disk).

It's not a huge deal-breaker but if the technical barriers are not great, it would be a nice choice to have.

[Intaris]

OK, I need to modify the post a little.

Apparently the compile cache stores only the path (on disk) of the VI when it stores information about it in the compiled cache.  This is, to me, not sufficient.

I re-use the same VIs on several different targets within the same project (or at least within the same disk storage area).  Recompiling a VI on a RT target will store the information apparently in the same location as the same VI on the host computer and the same VI on an FPGA target.  Now it seems logical why LabVIEW always asks me to re-save loads of VIs when sharing code across different targets.

So instead of asking for more control over deleting things int eh cache, a better idea would be storing some project or target-relevant information int eh cache to allow for better differentiation when sharing code across different targets.

tldr, forget this idea, efforts required elsewhere.

[Dragis]

@Intaris, the object cache uses the target and conditional compile symbols as part of the key to the cache. I have not noticed the behavior you describe with cache entries colliding, but there are times when the VI source itself uses features that for some reason require the VI to recompile when opened in different targets. That might be a case you are seeing.

[AristosQueue (NI)]

Intaris: I don't know what you're seeing, but the conclusion you're drawing is incorrect. The whole point of the Source Only feature is to allow us to store compilations for multiple targets, particularly RT and desktop at the same time.

[Intaris]

I obviously didn't look closely enough then.

Never mind.

[Intaris]

I need to state that this idea remains valid

despite my orriginal "never mind".  I now change this to "mind". 🙂

We keep running into problems with our code which we can seemingly only rectify be nuking the compile cache.  Of course this affects everything on my development PC, which can lead to some painfully long load times for projects which are not affected by the problem.

It would be really nice to have a tool to inspect / selectively delete specific portions of the compile cache.  Especially, but certainly not limited to, deleting compile cache for "temporary" disk folders which have since been deleted.

[crossrulz]

I think it would make sense to add this to the project:  right-click on a target and choose to delete the compile cache.

[AristosQueue (NI)]

ctrl+shift+click on run arrow forces recompile of all VIs in memory. Load the VIs that you want and they will overwrite the obj cache.

When it comes out, LabVIEW 2018 SP1 will significantly improve the behavior of the obj cache. It should remove the bulk of bugs that necessitate wiping the cache.

Note that this idea remains open. The above two comments are meant only to help, not to be an reason for closing this idea.

[Intaris]

The ctrl+shift+click has serious shortcomings in that inlined VIs are not "re-compiled" as they should.  This has been our go-to method for a while but just yesterday we had a case where it did not yield the correct results, but clearing the cache did.

I still think some kind of inspector, irrespective of the number of bugs which may or may not be solved, to be highly advantageous.

[AristosQueue (NI)]

Inlined VIs are one of the areas that has received explicit and significant attention in the 2018 SP1 release.

[Intaris]

This is still aproblem BTW.