Jump to content

VI Object Cache shared between 32 and 64-bit?


fabric

Recommended Posts

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?

Link to comment

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.

Link to comment

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!

Link to comment

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)

Link to comment

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! :shifty:

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

Link to comment

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)

Link to comment

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.