Declined for reasons listed here: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Building-Executable-Installer-Show-information-about-h...
While building (specially) an installer (and/or executable), it is very good to display estimated time remaining and percetage completed.
I am not allergic to Kudos, in fact I love Kudos.
Make your LabVIEW experience more CONVENIENT.
This has been deeply and widely explored. LabVIEW does not and *CANNOT* know how long your build will take. There's this marvelous paper by Alan Turing laying out the Turing Halting Problem. Turing provided a mathematical proof that under one simple condition, no one can know how long a program will run any faster (with a constant factor C) than actually doing the work. Trying to say how long a program will take to run becomes impossible as soon as you introduce any conditional statement into the operation based on an external input stream -- in this case, the external input stream is the content of your files. As we add each file to the system, we discover new optimizations that can be applied and new dependencies that have to be processed. This means the build time is open-ended and small changes in your code can have huge ramifications on the time.
Now, just because we can prove that we can't know algorithmicly, you might suggest that we could have some rough huristic. We've tried that. Doesn't work. Had a small team work for almost a year just trying to get a decent prediction of the time needed to load the VI hierarchy into memory. We can't even predict that with even a first order precision. The time needed to do the full build is even more erratic.
The execution time of compilers is one of the great unknowables of the universe that all programmers just have to deal with.
We don't know the percent complete, for the same reason -- we'd have to know how much there is to do. As the compiler runs, it discovers, VI by VI, more things to do.
Consider what you see when you load a VI hierarchy. The progress dialog appears that says how many VIs we have loaded. For each VI, we don't know the size of its hierarchy until we load each subVI and find out how many subVIs are hidden under that, so we can never say "you are X% done with load" because we don't know how many VIs will be loaded. That project I mentioned above tried various things like saving the list of subVIs at the head of the file so all we had to do was read that header information and then we could pre-flight all the VIs and count them before doing the real load. But that preflight requires touching each file, and opening and getting the disk seek head to the right place is a huge time sink compared to just finishing the full load on one read.
Pretty much any way you slice it, you can't get any information about the load faster than just doing the load. With compile and the various optimization passes that AppBuilder makes, the problem is worse.
There's no way around the knowable information limit.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.