LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
gt3000

Progress bar when loading dependencies

When you launch a LabVIEW Project or Top Level VI with many Sub VIs, it can take some time while LabVIEW searches and loads all dependencies.  This is especially true when working with large RF applications.  Better CPUs and SSDs make the loading faster, but the loading time is still fairly long for most PCs.

 

I propose that the 'Loading Dialog', which normally shows 'Ignore Item', 'Ignore All', 'Browse' and 'Cancel' is augmented to have a Progress Bar.  Seasoned LabVIEW users are familiar with the process of loading files, however, new users will find the progress bar less daunting than a dialog box with lots of text flashing on their screen with complex words like 'Loading', 'Searching' or 'Mass Compiling'.

 

I would like to take a cue from the Windows 8 Copy/Paste dialog box, where a standard progress bar is shown, unless you request to see more information.

 

Proposed New User Experience:

LVloadcrop.png

 

To get back to Classic User Experience: click 'more...', or if a dependency cannot be found:

LVload.png

 

Kudos if you like the idea.

 

George T.

George T.
Senior Applications Engineer
National Instruments UK and Ireland
13 Comments
SteenSchmidt
Trusted Enthusiast

It might not be possible to know from the start how many items in total needs loading, which is a prerequisite for a progress bar. A progress bar that reverses (as additional dependencies are discovered) is of no use IMO.

 

But if it was, I'd also like a progress bar in this dialog (and I like the "more..." link as well).

 

Cheers,

Steen

CLA, CTA, CLED & LabVIEW Champion
gt3000
NI Employee (retired)

Yes, I agree that it may not be possible, as that would imply that the total number of files would need to be known, however, I did not propose an 'accurate' progress bar.  I said 'Windows' style, which implies that it's a 'good enough' effort that most users could be used to already from their OS. 😉

 

Don't forge to Kudos!

George T.
Senior Applications Engineer
National Instruments UK and Ireland
crossrulz
Knight of NI

gt3000 said:

I did not propose an 'accurate' progress bar.  I said 'Windows' style


1 minute remaining...45 seconds remaining...5 minutes remaining...25 minutes remaining...2 seconds remaining...


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
muks
Proven Zealot

That is exactly what came to my mind too but on the whole will give a rough idea atleast. So kudos

crossrulz
Knight of NI

The Generate Intermediate Files for the LabVIEW FPGA module's compile process has this issue as well and it has a progress bar.  It is at least an eye ball check based on the current information.  So I say let's go for it!


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
AristosQueue (NI)
NI Employee (retired)

I am going to close this idea. We had a new hire investigate this problem and for a solid year for LV2013. He dragged in all sorts of people into the brainstorming, and built numerous prototypes. Eventually, we gave it up as a lost cause. It is a fundamentally intractable problem.

 

The problem with a progress bar is that you have to know in advance where the end is. You can't  just make up numbers. In fact, we tried that. "Let's just pick a number, say, 100, and every time you load a subVI, we'll move forward by 1 and then we'll just hang at 99 until done." We tested it out to see whether it was a viable idea or not. Problem is that the progress bar is useless in those conditions. In small hierarchies it gets to some small percent and jumps to the end; in larger hierarchies, it gets to 99 and spends half hour there. The whole goal of a progress bar is to let you know how long you have to go get coffee, and it didn't work for any of these.

 

So we tried doing some sort of read-ahead for subVI information without actually loading the subVIs, but that created so much disk seeking that the load time substantially increased. If we tried to minimize the disk seeking, we were spending so much time calculating the progress bar that more time was spent during the first phase without a progress bar than during the second phase with it.

 

We tried creating caches so that the first time you loaded you wouldn't get a progress bar and then subsequent loads you would, but that created one more cache to keep up-to-date and you still could have your whole progress bar wiped out if even a single VI in your hierarchy had changed on disk -- because that one subVI could be modified to drag in a new hierarchy as large as your entire cached hierarchy... and you wouldn't know that it was going to blow the progress bar away until you reached that point in the load!

 

With Copy/Paste, you know how much work is to be done. Same with FPGA compile. It might move in fits and starts, but it averages out over time. With load, we have no idea how much to load.

Darren
Proven Zealot
Status changed to: Declined
InfiniteNothing
Active Participant

Maybe if you displayed the numerics (eg n out of m loaded, where n and m where calculated as you go), you could go get coffee once you noticed m was a huge number.

CLED (2016)
RavensFan
Knight of NI

But the number loaded vs. the number it knows to load at that point of time are probably both increasing at roughly the same rate.

AristosQueue (NI)
NI Employee (retired)

RavensFan: That (surprisingly, I agree) turns out to not be true. We looked a many large hierarchies... you'll get whole swarms of VIs that are only one level deep and then hit a VI representing a major subsystem that adds a whole bunch. Those turn out to be fairly poor architectures, but they also seem to be fairly common architectures.