fabric Posted November 22, 2012 Report Share Posted November 22, 2012 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
asbo Posted November 22, 2012 Report Share Posted November 22, 2012 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
fabric Posted November 22, 2012 Author Report Share Posted November 22, 2012 Ok... here's my test: Open LV32 Make a new VI, save it Close LV32 Check timestamp of "objFileDB.vidb" file. Open LV64 Open previous VI and run it (but don't save it) Close LV64 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
MikaelH Posted November 22, 2012 Report Share Posted November 22, 2012 That's not good, this means I probably need to keep the source inside the VIs :-( Link to comment
Ton Plomp Posted November 22, 2012 Report Share Posted November 22, 2012 Does it help if you use seperate LabVIEW data folders? Ton Link to comment
fabric Posted November 22, 2012 Author Report Share Posted November 22, 2012 (edited) 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 Link to comment
JamesMc86 Posted November 22, 2012 Report Share Posted November 22, 2012 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
fabric Posted November 22, 2012 Author Report Share Posted November 22, 2012 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... Link to comment
fabric Posted November 22, 2012 Author Report Share Posted November 22, 2012 Cross-posted to the blue side: http://forums.ni.com/t5/LabVIEW/VI-object-cache-shared-between-32-and-64-bit/td-p/2230316 Link to comment
JamesMc86 Posted November 23, 2012 Report Share Posted November 23, 2012 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
Mr Mike Posted November 23, 2012 Report Share Posted November 23, 2012 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: Open LV32 Make a new VI, save it Close LV32 Check timestamp of "objFileDB.vidb" file. Open LV64 Open previous VI and run it (but don't save it) Close LV64 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
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now