LabVIEW 2015 - Fast File Format and PlugIn Architecture

[arteitle]

Fast File Format also breaks Remote Front Panel access with a cryptic error message, see my previous thread here.

[dadreamer]

---

@dan.bailey@dan.bailey wrote:
In a DLL/EXE/LVLibp we know at build time what the contents and dependencies of a given built binary are going to be.  With this knowledge we can go ahead and construct something that is more similar to a statically linked PE or ELF file (clearly we're not using either of those)

---

I'd like to ask on this note...

Am I right that LEIF binaries as forementioned PE, ELF or Mach-O are kind of machine compiled entity and cannot be back-translated into "traditional" LV resources? It's a known fact, that non-FFF LV-built .exe, .dll or .lvlibp still have the original VIs embedded (without BDs, ofc). In order to run that executable LVRT loader has to read out the resources' forks and properly link their data with the main app instance. How it goes with FFF-enabled executables (are there the classic resources or is it something completely different)?

The second question is about LEIF loader itself. Now it's strictly internal to LabVIEW. But will it ever be documented and openly available to have a possibility to use LEIF as external resource in another IDEs? It would be nice to reuse that highly optimized cross-platform code.

[Thomas_robertson]

I just wanted to zombie this thread to throw out some more caution about the "Fast File Format" checkbox.

We turned it on because our application takes around a full minute to launch on some machines (24 seconds on very very fast machines).  For the most part it made no improvement (I don't think we saw any launch speed improvement) other than making our 120Mb exe become a 60Mb exe.   Meanwhile it had side effects: paths appeared to be different when launching dynamic vis which caused some breaks.   More importantly one of our test cases (launching a bunch of actors and then harvesting them over and over again) slowed down by 300%+.   So whatever this barely documented flag is doing, it's not just transparently benevolent it's changing some under the hood stuff that can hurt you just as well as help you.  More documentation is needed and be careful using it.

[thols]

One more caution to add with FFF enabled: The startup VI of an EXE is displayed before the run-time position and other display properties of the VI is applied, so there will be some annoying flickering before the VI looks like it should (still in LV2022Q3). 

[avogadro5]

Resurrecting again, I encountered a strange one: enabling FFF actually fixes an exe issue. I get one of these unhelpful error codes when building with FFF disabled, but the program runs when built with FFF.

I'm still debugging what caused the problem without FFF, but it'd be helpful if this function were documented so I could understand what it did differently...

[Cepera]

I have revisited this feature in LV 2023 Q3 64-bit. The problem with the flashing window seems to be gone. I tested a couple of builds with FFF enabled on two machines: one with Core i7 CPU and M2 SSD and one with Core i3 CPU and mSATA SSD.

With all that said, I find this feature to be of minimal value: while executables that use this feature are about 30% smaller than without it, the load time is pretty much the same.

Still, it would be nice if someone else could test it and verify that the problem has been fixed. Then we could retire this thread.