LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

When should you clear the object cache?

Under what circumstances would it be advisable to clear the Compiled Object Cache? Do people only do that when a bunch of VIs are deleted, to free up HDD space? Or are there instances where object files can be corrupted/fragmented/etc?

 

I'm wondering what the benefits of clearing the cache are, in particular in case it might have a positive effect on my abysmally slow project load times (after the intial recompile, of course)....

0 Kudos
Message 1 of 3
(4,151 Views)

I will clear out the cache after completing a major project.  The only times I've heard of that you really need to clear out the object cache is if something isn't running right because the object file might have been corrupted.  Or you can just randomly clear it out to free up some harddrive space.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 2 of 3
(4,136 Views)

This is an old thread, but it came up near the top of the search results so it's worth updating.  Clearing the compiled object cache is useful for MUCH more than reducing disk space, and has saved my bacon many times.

 

The compiled object cache can occasionally (increasingly rarely these days, thankfully) get something corrupted in it - so if you get build errors, clearing it can be one of the first things you should try. 

 

Second (and far more common for me), there are plenty of cases where you may change a VI on disk, such as using source code control with a team and switching between branches.  If there's a change made directly on the disk as opposed to through the IDE, LabVIEW is terrible at checking it and invalidating the cache, so it can lead to the code that's executing being different than the current source VIs you're looking at.  It can lead to corruptions, bad or failed RT deployment, and more.  It's exacerbated by a few things - inlined VIs is one of them I know for sure, and interactions with RT are another recurrent theme (not every time, but certainly more often than non-RT code).

 

If I switch branches and pick up a co-worker's code, I always clear the cache if there was a change in an inlined VI.  And if there's ANY other weirdness, then the FIRST thing I do is close the project, clear the cache, and re-open the project.  (That's the other adjacent best practice - clearing the cache after you have the project open doesn't always do the trick.  Take the extra few moments to close the project, clear the cache, and re-open the project.  You're doing these steps to be sure you have a good state - so it's worth not taking shortcuts and making it almost-but-not-quite sure.)

 

That's what I've learned over the years.  If anyone has something else to add or correct, I'm anxious to know it!

 

Thanks,

Andrew

Message 3 of 3
(2,674 Views)