Eliminate Quick Drop's Initial Launch Delay

[Darren]

As much as I love Quick Drop, I don't love this:

This delay occurs because we have to load all the palette information in the background to be able to drop objects by name.  You can choose Tools > Options > Controls/Functions Palettes > Load palettes during launch to front-load this delay during LabVIEW launch, but (1) a lot of you don't really like the longer launch time much better and (2) a lot of users still don't know about this setting.

I'm sure there's a way to solve this problem and make Quick Drop instantly usable, but I don't know enough about the underlying palette code to get it done.  Solving this problem, by the way, could have positive side effects on LabVIEW launch time, palette search performance, and maybe some other areas as well.

[altenbach]

(Sorry, I am probably just rambling, because I don't know how things are done under the hood. :))

I would think that for long stretches the palette information does not change, and there should be a flag (registry entry, special file, or similar) to indicate if the palette has changed (e.g. after installation of a toolkit, etc.).

Then we should have a cached palette file that makes loading the palette and initializing QD very fast in the typical case where LabVIEW is opened, but the palettes have not changed. QD could even maintain it's own persistent cache somewhere.

[Mads]

And why would it not work to write and read a "last known" QL-list and then refresh it in the background? Darren's static list is a similar idea that removes the risk of the user hitting a stale entry in the last known list.

Today we have two choices: Load everything at starup - or load it on demand. I would say there is a third option: Load in background when idle.

It's annoying to have to wait while launching LV or when opening QL - but in reality there is plenty of idle time that could be used. Let's say you load LV quickly (happy user)...and the user starts by opening a project etc. etc...not much heavy processing going on. That is when you load QL etc.

[AristosQueue (NI)]

> Load in background when idle.

That is an option already in Tools >> Options. And, unless someone has putzed with something, it is the default option. We would load palettes as time permitted, and it was rare that you would browse down to a level that we hadn't already loaded. Sometimes a user would click Search and have to wait, but that wasn't common. But QD is a feature that a user would reach for in the first few moments  of launching LV, and QD only works if stuff is loaded into memory, just like search.

[Mads]

Yes there is such an option, but it does not look like QD is affected by it, or does it? I just did a quick test - launched LV, then waited 2 minutes with no activity...and still QD had to populate the list when it was launched.

[Darren]

---

Mads wrote:
...and still QD had to populate the list when it was launched.

---

I noticed similar behavior in LabVIEW 8.6, but I just tried in LabVIEW 2009...when I have "Load palettes in background" selected in Tools > Options, and I let my LabVIEW sit (with an open VI) for about 10 minutes, Quick Drop was pretty much instantly usable (it was "Populating List...Please Wait" for less than half a second).  And I've got a ton of modules/toolkits installed.  So maybe we tied up some loose ends with the lazy palette loading in LabVIEW 2009?

-D

[AristosQueue (NI)]

Lazy loading works fine in 8.5. I can't confirm 8.6 right now (don't have it installed), but I'm going to guess 8.6 has a bug somehow. In any case, assume that already exists in 2010 😉 ... it still doesn't solve the QD problem.

[BrianKincaid]

Put a button to the left of Shortcuts... that says "Refresh" and does the search (current on-load functionality). 

By default have QuickDrop load an index file that is the previous session search result.  If users don't change their palletes or search locations often like me then quick drop will load just as fast as it will the 2nd time!  If I want to refresh I push the button and it makes a new index file.

-Brian

[mattjsimps]

This SO needs sorting out. It just completely destroys your flow.

Compare this to auto-complete functionality in IDEs for text based languages. Slickedit, Visual studio etc. Alt-space (or whatever your shortcut is), and it not only populates a list of variables, functions, header files - anything pretty much, but it does it instantly, more or less, and typically guesses the one you are likely to want based on the current context. And does it instantly - did I already mention that?

The other thing that desperately needs fixing is its tendency to following the first load, switch to a completely different window - maybe the project, maybe some other  BD. IT rarely sticks on the diagram you actually want.

@Darren - well said. Its not us, the users, problem to figure out how to implement it.

Personally, I would like to see palletes loaded - quite often I know what pallete something is, but can remember the exact name. Was that "Pack cluster by name" or "bundle".

But I dont see why it cant either cache the results and update them in the background. At the very least it should present the results as they are loaded, and allow us to start typing the name before it has loaded them all.

But the real clincher argument here, i think, is that it clearly caches the results after the first load, so why cant it persist that cache? 

[AristosQueue (NI)]

> This SO needs sorting out. It just completely destroys your flow.

There's also a Tools >> Options setting to load the palettes as LV launches. That takes the few second hit when you're launching LV but avoids the flow break once you start working.

I'm just pointing out workarounds, not saying this shouldn't be addressed.

[David_L]

Looks like this is solved in LabVIEW 2011!