VI object cache shared between 32 and 64-bit?

[fabric]

Cross-posted from LAVA: http://lavag.org/topic/16349-vi-object-cache-shared-between-32-and-64-bit/page__pid__99898

I am currently working on a large project that needs to be deployed in both 32-bit and 64-bit flavours. This means I need to periodically switch between installed LV versions to build.

It *seems* that if I have been working in 32-bit LV, and then I close everything and reopen my project in 64-bit LV, that everything needs to recompile... even if I had only changed a few items since I last worked in 64-bit.

It appears that while LV does keep a separate VI Object Cache for each LV version, that it does NOT keep a separate cache for 32- and 64- bit versions. Is this really the case?

[tannerite · Accepted solution]

Hi fabric,

LabVIEW does keep separate caches for the 32- and 64-bit versions of the same release, but in the same file. So they are separate entries in the objFileDB. Since 32- and 64-bit are very different beasts, the project needs to be recompiled to adapt to the new platform each time you open it in a new environment. It is possible to separate the compiled code from the source code. Looking in other forum posts, this separation will likely cause a higher likelihood of VI corruption.

Best,

tannerite

[fabric]

---

@tannerite wrote:

LabVIEW does keep separate caches for the 32- and 64-bit versions of the same release, but in the same file. So they are separate entries in the objFileDB.

---

Good news! 

My initial observations were that a substantial recompile was required after switching LV versions, even after very minor edits. Since I am separating compiled code throughout my project, I expected that the recompile time would be much less...

It now seems likely that some of my "minor edits" may be forcing more recompiles than I suspected.

Anyway, thanks for clarifying that 32- and 64- bit code is cached separately.

[Hooovahh]

This is an older post but I have a related question.  It was stated that VIs may have multiple entries for a single VI since the VI maybe compiled for different targets.  Is this also true for other targets such as RT?  If I open a VI in both Windows and RT does the compiled cache have two entries for both targets?

I ask because I'm having some frustrations where opening the same set of VIs from RT and from Windows.  If I open them both from within the same project I'm forced to compile a couple hundred VIs (out of a couple thousand) and every time I reopen in a target that it was not last compiled for, I need to recompile those VIs again.  It now takes something like 10 minutes on my I5 SSD computer to open a project because no matter how I open it I need to recompile at least once, some times twice.

[Jorr-El]

Could you explain a little more what you mean by opening a VI in both Windows and RT? Are you going into the Linux OS or are you doing everything from a LabVIEW project on Windows? 

I have some debugging tips for you as well that you could try to see why opening the VIs is taking so long:

• Source control
  • Are you using source control? Could your source control configuration in LabVIEW be interfering with access to the VIs or dependencies?
  • Do you have the main VI or subVIs set to save as Source Only?
• Disk/memory issues
  • Are you (close to) running out of hard drive disk space or memory while loading?
  • Run a chkdsk on your hard drive to check for any corruption; possibly defragment the drive
• Other
  • Disable Antivirus/Firewall

[Hooovahh]

I decided to post a related question where I explain myself a little better over on LAVA.

The summary of that thread is this.  I have a single project in Windows with two targets, a Windows and an RT, both with separate main VIs.  Both Main VIs share a large percentage of the same code, both from user.lib reuse libraries (OpenG, MGI, Internal) and about 12 of the 15 libraries made for this project are shared between both targets.

If I open the project, then open the Windows Main.vi I see a dialog loading the VIs and then compiling about 200 of them.  If I then open the RT Main.vi I see the same dialog loading the VIs and then the same 200 get compiled.  I then do a save all and close the project.  If I open the project and then open the Windows Main.vi I then have to recompile those 200 VIs again, and if I open the RT Main.vi I have to recompile those again.

After seeing this I started searching for other issues with the compile cache which is how I ended up here asking about if targets also get separate compiles in the same way bitness apparently does.

As mentioned in the LAVA thread I wiped my compile cache and resaved the project and now the number of VIs that continually need to be compiled is around 20. 

No it is not a SCC thing (SVN is used but not between all the mess of compiling). Separate compiled code is on for the majority of the code but not all (OpenG for instance doesn't have it on).  The VIs that show the compile dialog are a mix of some having separate compiled code and some not.  My disk has about 30GB free.  I can run chkdsk but it is an SSD but some of the errors chkdsk is made to find won't be found on an SSD, and as for defrag with volume shadow copy on (which it is by default) a defrag will happen automatically once in a while anyway.  Virus scan and firewall are not an issue.  These development machines don't have any.

[stevem181]

Hooovahh,

For systems with RT targets I use separate projects for the host (Windows) and RT code. This way I only have to recompile when switching between the two projects.

95% of the time I am not connected to hardware. For development, I need to be able to run both RT and Windows code at the same time. So I’m usually running the RT code on Windows (including the Network Streams interfaces). This would not be possible (AFAIK) if both are in the same project.

How this is done:

The RT code uses Condition Disable (TARGET_TYPE) structures to compile to the current OS (RT or Windows). Where there is hardware interaction, in Windows mode, data is simulated for inputs and outputs are bypassed. Other RT specific code is handled the same way. For functions like PIDs, you won’t get real results because the feedback is simulated (and therefore not realistic), but you can see them “trying” to work.

In the Host project I include a vi with the RT Main vi(s). I can either run this vi separately or place the RT Main(s) directly on the host block diagram.

At startup, the Host checks to see if the RT code is in memory and adjusts the Network Stream configuration.

---

This is meant to be an overview. I may have missed some of the details.

[Hooovahh]

That's an interesting design that I hadn't thought about.  I too have the ability to run my RT code on Windows, but I don't break it up by project, I break the code components into libraries, which are included in both the Windows and RT code, and then either tell the RT code to do things (via network streams) or tell the same set of code to do actions locally.  In this case the RT code is more or less a subset of the Windows code.  Tests can run locally in Windows, or remotelly in RT, but the RT doesn't have some of the UI and configuration that Windows has (for obvious reasons).

So last night I uninstalled all LabVIEW 2015 code, restarted several times, cleaned things up, and reinstalled 2015 and the RT module.  Today I still have some recompiling issues when going back and forth.  Here are two videos (because they are limited to 5 minutes using jing).  The first shows opening a project, opening the Windows Main, showing the compile window, then opening the RT main showing the compile window, then resave everything, close the project and reopen.  The second video shows re opening the Windows and RT main showing that files have to be recompiled yet again.

Part 1

Part 2

It is a pain and is only getting worst as the project grows.