VI Object Cache shared between 32 and 64-bit?

[fabric]

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?

[asbo]

That would be very strange; the 32-bit and 64-bit IDEs are all but guaranteed to produce different binaries, but I can't speak with confidence about it. You could clear your cache, compile a VI in 32-bit LV, pick a file to watch, then open it in 64-bit LV and see if that same file is messed with again.

[fabric]

Ok... here's my test:

1. Open LV32
   
2. Make a new VI, save it
   
3. Close LV32
   
4. Check timestamp of "objFileDB.vidb" file.
   
5. Open LV64
   
6. Open previous VI and run it (but don't save it)
   
7. Close LV64
   
8. Check timestamp again and notice that it has changed.
   

If I open my VI in a different version of LV but don't run it, then the timestamp of my obj cache file doesn't change.

Conclusive? Maybe not... but interesting!

[MikaelH]

That's not good, this means I probably need to keep the source inside the VIs :-(

[Ton Plomp]

Does it help if you use seperate LabVIEW data folders?

Ton

[fabric]

Does it help if you use seperate LabVIEW data folders?

Ton

Maybe... How do I do that??

(I'm running LV 2012, by the way)

Edited November 22, 2012 by fabric

[JamesMc86]

I think this is probably due to the fact that 64 bit is a different platform. This means you open the VI and the compiled code is for the wrong platform which forces a recompile. Even with a seperate object cache I think that because the compiled part of the VI file is for another platform it has to start again

(null)

[fabric]

I think this is probably due to the fact that 64 bit is a different platform. This means you open the VI and the compiled code is for the wrong platform which forces a recompile. Even with a seperate object cache I think that because the compiled part of the VI file is for another platform it has to start again

(null)

Right.... but if there was a separate VI obj cache for each platform, then most VIs would NOT need to be recompiled when switching versions.

At least that's how I think it should be!

My current project contains around 5000 VIs, so the unwanted recompile is a bit of an inconvenience...

[fabric]

Cross-posted to the blue side: http://forums.ni.com/t5/LabVIEW/VI-object-cache-shared-between-32-and-64-bit/td-p/2230316

[JamesMc86]

It's true the cache should contain all that is needed although I wonder if changing platforms has more practical issues in tracking the changes, at the minute I have not been able to dig out much on the algorithm that is used.

As a thought is this something where packed project libraries could help? You could have most of the code compile for x64 in these which will alleviate the issue if your code organisation suits this. I guess it would require a change in dependency locations as well though so maybe not

(null)

[Mr Mike]

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?

The VI Obj Cache allows multiple entries for a single VI depending on how it was compiled (e.g. for x86 or x64).

Ok... here's my test:

1. Open LV32
   
2. Make a new VI, save it
   
3. Close LV32
   
4. Check timestamp of "objFileDB.vidb" file.
   
5. Open LV64
   
6. Open previous VI and run it (but don't save it)
   
7. Close LV64
   
8. Check timestamp again and notice that it has changed.
   

If I open my VI in a different version of LV but don't run it, then the timestamp of my obj cache file doesn't change.

Conclusive? Maybe not... but interesting!

The VI Obj Cache is touched every time LV runs. It's been a while since I played around with it, but I believe there's a time stamp for the last time the compiled code was used. That explains why it gets a new modtime.

We'd really need more information to diagnose exactly what is happening. Exactly what, I'm not sure, but I'll forward this thread onto someone who knows more about it.